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ABSTRACT 


This  volune  focuses  priaarily  on  detaiLed  instructions 
for  affectively  using  the  Tile  Structuring  and  Pile  Revision 
Coaponents.  A brief  introduction  to  these  systea  coaponents 
ani  a inscription  of  expected  output  are  given. 
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Sect  ion  1 


INTRODUCTION 


File  Structuring  (PS)  is  the  initial  phase  in  designing 
a new  file.  In  structuring  the  file,  the  user  determines 
the  type  of  data  which  should  be  included  in  the  file  and 
the  order  of  grouping.  The  structured  data  table  is  then 
referral  to  as  a Pile  Foraat  Table  (PFT) . An  FFT  is 
generated  for  each  file  and  is  the  basic  outline  used  foe 
performing  file  aaintenance,  output  processing,  and  data 
retrieval. 

PS  can  also  be  used  to  describe  a non-NIPS  data  file. 
In  this  node  the  user  describes  the  contents  of  an  existing 
file,  including  record  control  fields,  record  type  fields 
anl  non  accessible  FILLER  fields.  The  resulting  FFT  is  used 
by  the  2UIP  coaponent  for  querying  the  non-NIPS  file. 
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Sect  ion  2 


FILE  STRUCTURING  COMPONENT 


2.1  Pile  Structuring  Prograa 

Tor  input  the  File  Strncturing  prograa  requires  a deck 
of  cards  which  contains  the  paraaeters  defining  the  file 
format.  These  paraaeters  are  used  to  develop  a table  which 
pro vidas  the  definition  of  the  file  foraat  to  the  rest  of 
the  systen.  The  File  Foraat  Table  (FFT)  contains  not  only 
tha  specifications  of  the  internal  foraat  of  the  file,  but 
also  partial  specifications  of  the  external  foraats  and  the 
data  conversion  required  between  the  external  and  internal 
forma  ts. 

Briefly,  the  paraaeters  in  the  input  deck  which  define 
the  file  record  foraat  to  P S include: 

File  ID  (File  Naae) 

Record  ID  (Record  Control  Group)  fields  or  groups 

Subroutines  used  for  input  and  output  conversion  of 
field/group  data 

Subroutines  applied  to  keyword  fields  to  scan  the 
transaction  data. 

Tables  used  for  input  and  output  conversion  of 
field/group  data 

Tables  applied  to  values  within  keyword  fields  to 
deteraine  if  the  ralue  is  a keyword. 

Edit  control  words  for  output  of  fields  or  <^oup3 

Field  naaes  with  sixes  and  nodes  (alphabetic  or 
nuaer  ic) 
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Group  nues  with  list  of  all  fields  included  within 
the  group. 


Labels  for  output. 

Fields  or  groups  to  be  used  as  file  indexes 

Fields  or  variable  sets  to  be  used  as 
f iel  ds. 

For  a non-NIPS  FS,  the  following  parameters  are 
in  the  input  deck: 

Record  format  definition  to  assign  a set 
number. 

Record  type  fields  to  contain  the  recor 
type  code. 


keyword 
inclu  ded 

sequence 

d format 


2.2  General  File  Concepts 

Files  have  a definite  structure  or  pattern  called  the 
file  format.  When  data  is  grouped  according  to  file  format, 
each  group  contains  a complete  description  of  an  activity, 
event,  person,  or  thing.  Bach  of  these  groups  is  called  a 
fils  record.  Thus,  a Formatted  File  is  an  ordered 
collection  of  file  records. 

The  file  record  is  a collection  of  elements  of  data 
arranged  in  the  pattern  specified  by  the  file  format.  The 
smallest  unit  of  data  is  the  field/record  element.  Each 
fiald  has  a defined  length  and  contains  only  one  specific 
type  of  data.  If  the  data  content  of  the  field  is  fixed, 
ths  fisLd  is  labeled  a fixed  field  and  will  appear  only  once 
within  the  file  record.  In  addition  to  fixed  fields,  a file 
nay  have  periodic  fields  which  may  appear  more  than  once 
within  a file  record. 

Hithia  the  file  record,  a closer  relationship  can  exist 
between  some  of  the  fields  than  exists  between  other  fields. 
Fields  are  often  reported,  retrieved,  and  manipulated  as  a 
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unit  caLLed  a group.  Groups  are  collections  of  two  or  nore 
fields  within  a file  record  and  Bay  be  considered  as  a 
single  data  entity.  The  fields  within  the  group  do  not  lose 
their  individual  identities  because  of  this  grouping  and  nay 
be  treated  like  any  other  field.  Groups  are  categorized  as 
either  periodic  groups  or  fixed  groups,  depending  upon  the 
types  of  fields  which  are  grouped.  Fixed  and  periodic 
fields  caanot  be  included  within  the  sane  group. 

Periodic  fields  nay  occur  any  nuaber  of  tiaes  within  a 
file  record  and  the  change  of  a value  recorded  in  one 
periodic  field  is  usually  accoapanied  by  changes  in 
associated  periodic  fields.  Periodic  fields  containing 
related  inforaation  are  grouped  into  units  called  subsets, 
when  periodic  data  is  added  to  a file  record,  it  is  usually 
added  in  units  of  subsets  rather  than  individual  fields. 
This  is  not  aeant  to  iaply  that  individual  fields  of  an 

existing  subset  cannot  be  corrected  or  updated.  It  is  the 
subset  structure  which  is  specified  by  the  file  foraat, 
while  provision  is  aade  for  the  entry  of  as  aaay  identically 
structured  subsets  as  are  necessary.  Periodic  subsets 
having  identical  fornats  are  grouped  together  into  periodic 
sets.  Thus,  each  periodic  subset  within  a periodic  set 
contains  the  sane  field  in  the  sane  order,  with  only  the 

data  content  of  the  fields  varying.  Periodic  subsets  of 

other  fornats  are  grouped  into  other  sets.  There  is  no 

liai.tati.oi  on  the  nuaber  of  periodic  subsets  within  a 
periodic  set.  However,  the  nuaber  of  periodic  sets  per  file 
record  is  United  to  a aaxinun  of  255. 

The  collection  of  all  the  fixed  fields  of  a file  record 
is  called  a fixed  set.  Since  fixed  fields  are  nonrepetitire 
within  a file  record,  there  is  only  one  fixed  set  in  any 

file  record. 

3ne  additional  type  of  data  nay  be  placed  in  a file 
record:  conaentary  inforaation.  This  unforaatted  data  aay 

be  placed  in  a variable  set,  defined  as  a single  field  with 
an  unrestricted  length.  This  data  aay  be  accessed  for 
retrieval  by  eaploying  one  of  two  capabilities.  The  first 
aethod  is  to  use  the  CONTAINS  operator  at  retrieval  tiae. 
The  second  method  is  to  use  the  Keyword  Indexing  capability. 
If  neither  of  these  aethods  is  used,  data  froa  a variable 
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set  sap  not  be  retrieve!,  bat  say  ba  displayed  along  with 
othar  data  elements  of  a file  record  during  output 
processing. 

An  exanple  of  a file  record  is  shown  in  figure  1.  The 
fonat  illustrated  would  correspond  to  a data  file  which  was 
structured  with  a fixed  set  containing  data  elenent  nanes  PA 
througi  PM,  one  periodic  set  with  elesent  nanes  1A  through 
IP,  another  periodic  set  with  elenant  nanes  2A  through  2H, 
and  a single  variable  set  for  renarks.  A record  control 
group,  which  contains  data  to  identify  each  file  record, 
nust  be  defined  as  the  first  data  elanant  (s)  of  the  fixed 
set.  It  appears  in  the  graphic  layout  as  the  tern 

REORD  ID.  A data  record  will  appear  internally  to  the 
naoiina  as  one  or  nore  logical  records,  each  of  which  is 
prefixed  with  the  contents  of  the  record  control  group. 
This  technique  causes  the  association  of  nany  internal 
logical  records  to  be  classed  as  a single  file  record 
externally  for  the  user.  Specifically,  an  internal  logical 
record  is  used  to  contain  the  data  for  a fixed  set  or  a 
single  subset  of  a periodic  set.  The  portions  of  the  file 
record  labeled  as  RECORD  ID  also  contain  sone  systen 
generated  and  naintaiued  data  elenents  used  to  differentiate 
the  logical  records  anong  the  periodic  sets  and  the  sequence 
nuabers  of  subsets  within  a periodic  set. 
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A aore  detailed  account  of  the  foraat  of  a file  record  and 
i Inscription  of  the  file  foraat  table  generated  by  the  file 
structure  appear  in  the  appendix  of  the  Introduction  to  Pile 
Concepts  (Voluae  I)  . 

Data  is  stored  in  the  systea  data  files  in  several 
different  foraats  or  aodes.  Although  it  is  possible  to  use 
the  systea  without  full  understanding  of  the  intricacies  of 
data  node,  systea  efficiency  can  be  iaproved  by  correct 
spacif ication  and  usage.  Pour  specific  nodes  of  data 
storage  are  used  by  the  systea:  Alphaaeric,  Deciaal,  Binary 
ani  Coordinate.  The  user  explicitly  controls  these  aodes 
when  using  alphaaeric  or  coordinate  foras.  However,  in  the 
cass  of  nuaeric  data,  the  3ystea  effectively  controls  the 
aode  and  the  user  assigns  the  aode  iaplicitly.  An  overall 
generic  tern,  NUHEH,  is  used  in  the  systea  and  iaplies 
nuaeric  data.  This  term  is  described  in  the  following 
sections  of  this  voluae  and  is  used  only  by  the  File 
Structuring  conponent.  Rote  that  neither  binary  nor  deciaal 
aay  be  specified  directly  by  the  user  except  for  subroutine 
attributes.  The  systea  assigns  one  of  two  aodes  to  every 
nuaeric  (NUBER)  field;  the  binary  aode  is  provided 
autoaatically  except  in  the  following  cases: 

a.  I hen  the  field  defined  by  the  NUHER  node 
statement  is  a part  of  the  record  or  subset 
control  group  (record  key  or  identifier),  the 
node  of  the  field  becoaes  deciaal. 


b.  when  the  field  defined  by  the  HJHER  node 
stateaent  is  included  within  the  range  of  a 
GROUP  stateaent  definition,  the  aode  of  the 
field  is  set  to  deciaal. 


During  aost  of  the  systea  processing,  the  analyst  need 
consider  only  alphaaeric,  coordinate,  and  nuaeric  (binary  or 
deciaal)  aodes.  In  soae  instances,  however,  he  is  required 
to  directly  reference  the  internal  systea  aode  in  precise 
terns,  and  aust  specify  alphaaeric,  coordinate,  binary,  or 
deciaal.  In  all  cases  where  aode  is  not  explicitly  stated 
by  the  analyst,  the  systea  will  provide  the  autoaatic 
conversion  necessary  to  "natch"  or  adjust  aodes  correctly. 
Only  in  cases  such  as  the  specification  of  subroutine 
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attributes  is  the  analyst  required  to  use  one  of  the  four 
specific  aodes  rather  than  the  three  generic  classes  of 
data. 


The  types  of  eode  specification  required  are 
specifically  discussed  on  a statement-  by- statement  basis 
throughout  the  remainder  of  this  voluae.  This  prelieinary 
discussion  is  intended  only  to  acquaint  the  user  with  the 
general  concepts  involved  in  internal  data  fornats. 


2.3  General  File  Structure  Statenents 

The  user  subnits  as  input  to  the  file  structure 
coaponent  a deck  of  statenents  defining  the  fornat  for  his 
file. 


The  subsections  which  follow  will  discuss  in  general 
terns  the  statenents  used  by  the  file  structure  language. 
Section  2.4  will  then  define  the  exact  fornat  and  syntax 
required. 


2.3.1  File  Identification 

The  first  statenent  in  the  file  structure  source  deck 
defines  the  file  nane.  The  data  file  nane  nust  be  unique 
and  conforn  to  nane  conventions  described  in  Voluae  I , 
Introduction  to  File  Concepts  section  2.6.3  MIPS  360  FFS 
Language  contents. 


2.3.2  Subroutine/Table  Identification 

Fach  subroutine  or  table  used  for  data  value  conversion 
is  identified  by  a subroutine  or  table  statenent. 
Furthermore,  a subroutine  or  table  statenent  nust  be  used  to 
describe  each  subroutine  or  table  to  be  used  by  any 
Secondary  Indexiag  function.  The  operator  nay  be  either  the 
tern  SOD  or  TIB.  The  optional  use  of  either  operator  is  to 
aid  the  user  in  distinguishing  between  his  conversion 
subroutines  and  tables.  The  following  paraaeters  nust 
appear  in  the  statenent: 
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S ubroutine /Table  Rm  - Identifies  a aodule  on  the 
systea  library  for  data  conversion. 

Use  Function  - Identifies  the  conversion  of  input 
lit  output  datd.  If  this  SOB/TAB  stateeent 
describes  a subroutine  or  table  to  be  used  by  a 
Secondary  Indexing  function,  then  either  CONVERT  or 
ANALTZE  aust  appear  here  as  the  Use  Punction.  This 
entry  describes  the  function  of  the  subroutine  or 
table  for  Secondary  Indexing  purposes  only.  A 
detailed  description  of  these  functions  is  found  in 
voluae  IV,  Retrieval  and  Sort  Processor. 

Size  of  Input  Data  - Indicates  the  length  in  bytes 
of  the  data  to  be  converted. 

Size  of  Output  Data  - Indicates  the  length  in  byte3 
of  the  converted  data. 

Bode  of  Input  Data  - Identifies  the  node  of  the 
data  to  be  converted. 

Bode  of  Output  Data  - Identifies  the  node  of  the 
converted  data. 

The  aode  specification  for  data  eleaents  is  stated  in 
exact  teras: 

a.  ALPHA  aode  is  used  to  reference  data  which  is 
represented  in  EBCDIC  notation  fora.  Eleaents  in 
a file  record  defined  as  ALPHA  aode  are  of  this 
char acter ist ic. 

b.  BINARY  aode  is  used  to  reference  data  contained  in 
a binary  word  (32  bits  of  nuaerical  significance). 
Eleaents  in  a file  record  defined  as  NUHER  aode 
(and  not  included  within  a group  definition)  are  of 
this  characteristic. 

c.  COORD  aode  is  used  to  reference  any  data  eleaent 
with  a systea  internal  coordinate  foraat.  Eleaents 
in  a file  record  defined  as  COORD  are  of  this 
characteristic . 
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5.  DECIMAL  lode  is  used  to  reference  any  data  eleeent 
defined  vith  a NOHER  node  and  included  within  a 
group  definition. 


A laxieua  of  50  subroutines/tables  eay  be  defined  for  a 
file  during  file  structuring. 


2.3.  2.1  Subroutioe/Table  Identification  for  Keyword  Osage 

when  subroutines  or  tables  are  applied  against  keyword 
fields  they  perforn  a different  function  (see  SOB  Statement 
for  Keyword  Osage  for  details)  but  the  sane  basic  rules 
apply.  The  following  parameters  appear  on  the  stateaent: 

Subroutine/Table  Nane  - Identifies  a nodule  on  the 
systen  library. 

Ose  Functions  - Identifies  one  of  three  functions.  STOP 
indicates  a table  containing  all  words  that  are  to  be 
eliainated  fron  keyword  processing.  DICTIONARY 

indicates  a table  containing  all  allowable  keywords  for 
the  field.  SCAN  indicates  a user  provided  subroutine 
that  is  to  extract  keyword  candidates  froa  a transaction 
record.  For  a detailed  description  of  these  tables  see 
Volune  I,  File  Concepts,  Keyword  Indexing  Capability 
section. 


2.3.3  Edit  Mask  Identification 

Each  user- edit  aask  east  be  defined  by  an  edit 
stitsasat.  The  operator  for  this  stateaent  is  the  tera 
EDIT.  The  following  para  asters  are  reguired: 

Edit  Mask  Naae  - A user -supplied  naae  to  identify 
the  edit  eask  when  used  as  a parameter  in  a field 
or  group  stateaent.  The  name  aust  be  unique  for 
the  file  and  follow  the  systea  naaes  rules. 
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Edit  Mask  - The  actaal  edit  aask  to  be  used  during 
output  conversion.  The  following  limitations  are 
imposed: 

Dp  to  50  edit  aasks  aay  be  defined  per  file. 

Each  edit  ask  aay  ba  up  to  69  characters  in 
length. 

The  sua  of  edit  mask  lengths  for  a single  file 
must  not  exceed  1,000  characters. 

The  rules  for  writing  an  edit  aask  are  specified  in  the 
Introduction  to  Pile  Concepts. 


2.3.4  Pile  Classification 

The  user  aay  identify  the  file  classification  at  file 
structuring  tine.  The  operator  for  this  stateaent  is  the 
tera  CLASS.  This  single  pa  rase  ter  aay  be  up  to  32 

characters  in  length.  If  this  stateaent  is  not  present,  the 

file  structured  with  no  classification,  i.e.,  the 

cl assifi  cation  is  set  to  blanks. 

The  stateaent  types  SUB,  TAB,  EDIT,  and  CLASS  aay  appear 
in  any  order  as  long  as  they  cone  after  the  file 

identif icatioa  stateaent  and  before  any  FIELD  definition 
stateaent. 


2.3.5  Field  Definition 

The  field  stateaent  defines  the  characteristics  of  each 
data  eleaent  in  t he  data  file  record.  The  user  writes  the 
stateamats,  defining  in  sejuence  the  entries  of  the  fixed 
set.  Periodic  Set  One,  Periodic  Set  Two,  etc.  The  following 
rules  apply: 

a.  The  fields  containing  the  file  record  control  data 
aust  be  defined  first. 
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b.  All  fields  in  each  set  aust  be  defined  together; 
for  exaaple,  all  fields  for  the  fixed  set  aust  be 
defined  in  a sequence  of  stataaents. 

c.  If  a periodic  set  has  fields  to  be  used  for  subset 
control  (standard  language  capability),  these 
fields  aust  be  defined  first  Ln  that  periodic  set. 

d.  If  a variable  length  field  is  defined  for  a set 
(standard  language  capability),  it  aust  be  defined 
by  the  last  stateaent  for  that  set. 

a.  When  defining  periodic  sets,  set  nuabers  aust  be 
specified.  For  exaaple,  a record  with  three 

periodic  sets  aust  be  assigned  the  auabecs  1,  2, 
and  3,  in  this  order. 

f.  Record  control  and  subset  control  fields  should  be 
defined  as  ALPHA  node. 

g.  Up  to  and  including  a aaxiaua  of  100  fields  nay  be 
defined  for  each  3«t  of  the  user's  file  record. 

h.  The  maxiaua  nuaber  of  characters  in  a set  aay  be 
det  "rained  by  referring  to  Tol  uae  I,  Introduction 
to  File  Concepts,  Appendix  A. 2,  Data  File  Records. 
By  knowing  the  size  of  the  record  control  field  and 
Largest  subset  control  field,  the  user  can  add  up 
the  systea  overhead  bytes  and  the  user  “defined 
control  fields  to  deteraine  the  naxiaua  nuaber  of 
noncontrol  characters  in  a set. 

The  following  teras  are  used  to  describe  paraaeters  in 
the  FIELD  stateeeat : 

a.  Eield_jJai§  - User-assigned  naae  to  the  field  which 
will  be  used  to  access  specific  record  data.  The 
naae  au3t  be  unique  within  the  file  and  follow  the 
sane  conventions  of  length  and  character  aode  as 
the  file  naae. 

b.  Field  Size  - Size  in  bytes  for  the  data  itea  as  it 
appears  in  the  data  record  (after  input  conversion. 
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if  used)  . Por  numeric  fields,  which  are  stored  as 
binary  wards  (four  bytes),  the  external  fora  length 
is  used. 

c.  Set  Number  - Number  defining  the  set  to  which  the 
field  will  belong. 

d.  Pield  Hade  - Tera  defining  the  node  of  the  field 
(e.  g.f  ALPHA,  HUHEB,  or  COOBD)  . 

e . Input  : on version  .fioutiae  _fiaaa  - Naa  e of  the 
subroutine  or  table  which  was  earlier  described 
with  a Sub/Tab  statement. 

f . Output  Conversion  Rout inq  Marne  - Name  of  the 
subroutine/  table  which  was  earlier  described  with 
a Sub/Tab  statement. 

g.  £4it_j§a§  - Name  of  the  edit  mask  defined  by  an 
edit  statement. 

h.  Pield  Label  - Label  of  up  to  69  characters  which 
lay  be  assigned  to  the  field  in  lieu  of  the  actual 
field  name  when  using  QUIP. 


2.3.6  Group  Definition 

The  group  statement  redefines  a seguence  of  adjacent 
fialds/groups  with  a new  name  which  nay  be  used  as  a data 
reference.  This  group  statement  is  a powerful  logical 
oparator  which  aLlows  the  manipulation  of  larger  segments  of 
related  data,  thus  increasing  machine  efficiency.  The 
following  conventions  and  rules  must  be  followed: 

a.  In  the  statement  string,  the  group  statement  must 
immediately  follow  those  statements  which  define 
data  elements  including  those  within  the  group. 

b.  All  elements  (fields  or  groups)  defined  within  a 
group  must  be  adjacent  to  one  another;  none  nay  be 
omitted.  Control  fields  and  noncontrol  fields  nay 
not  be  part  of  the  sane  group. 
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All  itets  appearing  in  a group  definition  nust 
belong  to  the  sans  set  of  the  data  record. 

i' . Definition  of  a group  including  other  groups  within 
its  range  is  per  nit  ted.  The  nun  her  of  levels  or 
■nesting"  permitted  is  unlinited. 

s an  exanple  of  these  rules,  consider  the  following 
fore  t and  the  pseudo  FS  statenents  which  define  the  foraat. 
Note  the  nesting  which  nay  be  done  and  the  sequence  in  which 
the  field  and  group  statenents  appear. 


SE 


STATEMENT  LIST 


LUt-fias.® 

QESE.at.2E 

FA 

FIELD 

FB 

FIELD 

FC 

FIELD 

GA 

GROUP 

GB 

GROUP 

FD 

FIELD 

FE 

FIELD 

FF 

FIELD 

GC 

GROUP 

FG 

FIELD 

GD 

GROUP 

FH 

FIELD 

GE 

GROUP 

FB,FC 
FA,  GA 


FD,  FB,  FF 


GC,FG 


FD,  FB,  FF,  FG,  FH  (or  GD,FH) 
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Tb » fallowing  for » at  depicts  a desired  structure.  The 
statement  source  includes  intentional  errors  illustrating 
coaeon  rule  violations. 

Set  Poraat 
Gi  SB 

Pi  PB  PC  FD  PE  PP  PG 


ST  AT  MEET  LIST 


liiUHS 

Operator 

2Ei£M.i_Ujt 

Pi 

FIELD 

------- 

PB 

FIELD 

PC 

FIELD 

— 

Gi 

GROUP 

Pi,  PC 

(1) 

PD 

FIELD 

PE 

FIELD 

PP 

FIELD 

PG 

FIBLD 

— 

GB 

GROUP 

PE  ,FF 

(2) 

(1|  This  stateaent  is 

invalid  because 

the  group 

definition 

oaits  field  PB. 

(2)  This  stateaent  is 

invalid  because 

the  group 

definition 

does  not  iasdiately  follow  the  iteas  that  it 

redefines. 

This  stateaent 

should  precede 

the  field 

stateaent  for  FG. 

The  aode  of  the  fields/groups  included  within  a group 
definition  aust  be  considered.  Soae  coabinations  are 
invalid,  while  others  cause  the  systea  to  redesignate  an 
alsient's  aode.  Table  1 shows  the  possible  coabinations  of 
aode  grouping  and  the  results. 
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Table  1.  Node  Grouping  and  Results 


User-Defined 

£E2Jitd._a2.Sa_ 

Case 

Results 

ALPHA  Group 

Contains  all  ALPHA 
defined  fields 

Rode  reaains  the  sane 

Contains  ALPHA  and 

MUHER  fields 

NUHER  fields  change  to 
deciaal  node;  group 
reaains  ALPHA 

Contains  all  NUHER 
defined  fields 

All  fields  change  to 
deciaal  aode,  group 
reaains  ALPHA 

Contains  any  COORD 
defined  fields 

Rejected! 

NUHEF  Group 

Contains  all  ALPHA 
fields 

Rejected! 

Contains  ALPHA  and 

NUHER  fields 

Rejected! 

Contains  any  COORD 
defined  field 

Rejected ! 

Contains  all  NUHER 
defined  fields 

All  fields  and  groups 
change  to  deciaal  aode 

CD3Sr  Group 

Contains  all  COORD 
defined  fields 

Rode  reaains  the  saae 

Contains  any  ALPHA 
or  NUHER  defined 
fields 

Rejected ! 
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Tha  following  ter*s  ace  used  to  describe  paraaeters  in 
a G8DDP  statement: 

a.  Group  Naae  - User-assigned  nase  which  sust  be 

unigue  to  the  file. 

b.  tUIAZStaac-Uat  - a list,  in  sequence,  of  all  the  1 

fields/groups  to  be  defined  within  the  new  group. 

c.  Group  Node  - Ters  designating  the  node  of  the  ) 

group. 

d.  Input  Conversion  Roqtipe  Nape  - Naae  of  a 

subroutine  or  table  which  was  described  in  a 

Sub/Tab  stateaent. 

e.  iaifiat__t2M£tsiajs  _fi2Siia£_J»at£  - of  a 

subroutine  or  table  which  was  described  in  a 

Sub/Tab  stateaent. 

f.  Group  Editing  - Naae  of  the  edit  aask  defined  by  an 
edit  stateaent  . 

g.  Group  Label  - Label  of  up  to  69  characters  which 
aay  be  assigned  to  the  group  in  lieu  of  the  actual 
group  naae  during  a QUIP  rw. 


The  user  aay  optionally  use  tha  group  stateaents  to  provide 
additional  naaes  for  single  eleaents  in  the  data  record.  A 
group  stateaent  referencing  a single  field  in  its  operand 
string  wLll  provide  a liaited  synonya  capability. 


2.3.7  Index  Definition 

The  INDEX  stateaent  defines  an  eleaent  of  the  data  file, 
aither  a field  or  group,  to  be  used  as  a file  index.  File 
indexing  concepts  are  discussed  in  Introduction  to  File 
Concepts,  Voluae  I. 

Any  field  or  group  that  is  defined  by  a field  or  group 
stateaent,  except  variable-la ng th  fields  and  not  exceeding 
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30  bytes  in  length,  nay  be  designated  as  a file  index.  One 
exception  to  this  rule  exists,  however.  If  the  field 
specified  is  a record  control  field,  and  the  length  is  the 
sane  as  the  record  control  field,  the  attenpt  to  specify 
that  field  as  an  index  will  be  rejected.  Cross-  index  ing  a 
file  by  Record  10  is  redundant  and  would  be  inefficient. 

Indexes  nay  be  fixed  or  periodic.  There  is  no  naxinun 
or  xiniiui  nunbec  of  indexes.  Indexing  is  an  optional 
capability,  and  any  or  all  non-varlable-length  fields  or 
groups  nay  be  specified. 

The  following  terns  are  used  to  describe  paraneters  in 
the  INDEX  statenent: 

a.  Field  Nane  - The  user-assigned  nane  of  the  field  or 
group  which  will  access  specific  record  data.  The 
field  or  group  nust  be  defined  by  a valid  FIELD  or 
GROUP  statenent.  An  index  field  or  group  cannot 
exceed  30  bytes  in  length. 

b.  Index  Qperatjgn  - (ADD  or  DELETE)  - Default  is  ADD. 
DELETE  is  used  to  elininate  an  existing  index.  It 
is  for  i se  by  the  Index  Specification  function 
perforned  by  the  Utility,  OTKDISPC. 

c.  Conversion  Subroutine  - (Optional)  This  is  the 

nane  of  a user-provided  subroutine  to  convert  data 
fron  data  file  fora  to  index  forn.  This  subroutine 

lust  have  been  identified  by  a SUB/TAB  statenent 

during  the  run  in  which  the  index  is  being 

specified,  and  it  nust  have  been  defined  as  a 

CONVERT  subroutine  or  table.  If  no  subroutine  is 
specified,  the  values  for  the  index  field  will  be 
in  their  internal  data  file  fornat. 

d.  Analyzer  Subroutine  - (Optional)  This  is  the  nane 

of  a user-provided  subroutine  used  to  analyze  and 
deternine  the  qualification  value(s)  for  any 

FUNCTION  operator  in  which  the  indexed  field/group 
is  a paraneter.  It  nust  have  been  defined  as  an 
ANALYZE  subroutine  or  table  on  a SUB/TAB  statenent. 
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2.3. 7.1  Index  Definition  foe  Keyword  Pields 

This  forut  of  the  INDEX  statement  defines  a field  or 
variable  set  that  is  to  becoae  a Keyword  Indexing  Pield. 
Por  a detailed  description  of  Keyword  Indexing  see 
Introduction  to  Pile  Concepts,  Voluae  I. 

Any  variable  field,  variable  set,  or  fixed  periodic 
alpha  field  that  has  been  defined  for  the  file  nay  be 
specified  as  a keyword  field,  the  only  restriction  being 
that  a field  aay  not  be  defined  for  both  secondary  and 
keyword  indexing. 


The  following  terns  are  used  to  describe  paraneters  in 
tha  INDEX  statenent  defining  a keyword  field: 

a.  £iH4_£l«S  * T he  user-assigned  nane  of  t be  field  or 
variable  set  that  will  access  specific  record  data. 
The  field  or  set  nust  be  defined  by  a valie  PIELD 
or  VS ET  statenent. 


b. 


c. 


d. 


Index  Operation  - (ADD  or  DELETE)  - Default  is  ADD. 
DELETE  is  used  to  eliainate  an  a listing  index  and 
is  used  only  by  the  Index  Specification  function 
perforned  by  the  Utility,  UTNDXSPC. 


KE  IN  PHD  - Designation  of  this  statenent  as  one  that 
defines  a keyword  field  rather  than  the  standard 
Secondary  Index  Pield. 


MOTE:  Por  a DELETE  operation  on  a keyword 

field,  the  KETROBD  parameter  is  optional. 
The  1 elate  operation  will  occur 
regardless. 

H yphap QLftSiflMSiffj)  “ The  user  can  control 

processing  of  the  hyphen  by  the  systea's  scan 
routine.  A hyphen  is  always  treated  as  a word 
separator  if  it  follows  a word  separator  character. 
If  it  is  followed  by  a text  character,  one  of  four 
options  can  be  applied.  TEXT  is  the  default  option 
which  neans  the  hyphen  is  to  be  treated  and 
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retained  as  part  of  the  value.  The  other  options 
are  DROP,  RETAIN , and  SEPARATE. 

DROP  - The  hyphen  is  either  superfluous  or  it  is 
a word  separator,  depending  upon  it3 
context  with  respect  to  adjacent 
characters.  It  is  superfluous  if:  (1) 

text  characters  izsediately  precede  and 
follow  it,  or  (2)  it  is  iaaediately 
preceded  by  a text  character  and  followed 
by  one  or  sore  blank  characters  and  a 
text  character.  In  this  case,  blanks  are 
considered  to  be  si^>erf luous.  If  neither 
of  these  cases  apply,  the  hyphen  is 
treated  as  a word  separator.  In  any 
case,  the  hyphen  is  dropped. 

J ETA  IN  - The  hyphen  is  subject  to  the  sane  rules 
as  the  DROP  option,  except  that  in  the 
two  cases  where  it  is  considered 
superfluous  it  is  retained  in  the  value 
as  a text  character. 

SEPARATE-  The  hyphen  is  always  treated  as  a word 
separator. 

e.  Stop  Table  - (Optional)  This  is  the  naae  of  the 

user  provided  table  that  is  to  be  applied  against 
the  values  in  this  field.  If  a value  is  found  in 
the  table,  it  is  to  be  elininated  fron  any  further 
consideration  as  a keyword.  If  a value  is  not 

present  in  the  table,  or  if  no  table  were 
specified,  the  value  bee  ones  a keyword  candidate. 
This  table  nust  have  been  identified  by  a SOB/TAB 
stateaent  and  have  been  defined  as  a STOP  table. 

f.  Dictionary  - (Optional)  This  is  the  nane  of  the 

user  provided  table  containing  all  nonliteral 
values  froa  this  field  that  nay  becoae  keywords. 
This  table  nust  have  been  identified  by  a SUB/TAB 
stateaent  and  have  been  defined  as  a DICTIONARY. 

If  no  dictionary  is  specified , all  values  in  the 
field,  unless  soae  were  elininated  by  a Stop  Table, 
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becoae  keywords.  Literal  words  always  becoae 
k eywor d3. 

g.  Scan  Subroutine  - (Optional)  This  is  the  naae  of 
the  user  provided  subroutine  that  is  to  be  invoked 
to  process  the  keyword  field.  This  subroutine  oust 
have  been  identified  by  a SUB/TAB  statement  and 
have  been  identified  as  a SCAN  subroutine.  If  no 
subroutine  is  specified,  the  system's  scan  routine 
will  deteraine  what  qualifies  as  a value  for 
keyword  selection.  See  Voluae  I;  File  Concepts, 
3 ser  Scan  Subroutine  section,  for  a generalized 
description  of  the  systea  scan  routine. 


2.3.8  Variable  Set  Definition 

The  VS  ET  stateaent  defines  a variable  set  containing  a 
single  field  which  aay  be  used  to  store  coaaentary  data  in 
textual  fora.  There  is  no  practical  liait  to  the  aaount  of 
data  which  aay  be  placed  in  this  set. 

The  stateaent  operator  is  the  tern  VSET.  The  paraneters 
used  are  as  follows: 

a.  Variable  Set  p§se  - User-assigned  naae  unique  for 
the  file.  Wane  conventions  defined  in  Voluae  I, 
Introduction  to  Pile  Concepts,  apply. 

b.  Display  Size  - Value  expressing  the  size  of  data  to 
be  printed  per  line  during  QUIP  coaponent 
processing. 

c.  Iatilfele_5.fit_ta.ttl  - Label  of  up  to  69  characters 
aay  be  used  in  lieu  of  the  naae  during  QUIP 
processing. 

Tha  variable  set  stateaent  (s)  should  appear  in  the 
soarce  deck  after  all  field  and  group  stateaents.  Since  no 
operand  is  used  to  designate  a sat  nuaber,  the  file 
structure  coaponent  will  autoaatically  assign  the  next  set 
available.  For  exasple,  if  the  last  periodic  set  defined  by 
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ttia  us»c  through  field  and  group  stateaents  was  18,  the 
first  variable  set  would  be; one  set  n usher  19. 


2.3.9  End-of-Job  Statenent 

The  »»d-of-job  statenent  appears  last  in  the  source- 
statenent  deck.  It  signifies  the  conpletion  of  file 
definition.  It  contains  the  operator  tern  EM DPS  and  has  no 
paraaeters . 


2.3.10  User  Coaaentary  Statenent 

If  the  user  desires  connentary  renarks  on  the  source 
listing,  this  capability  is  provided  by  the  NOTE  statenent. 
It  nay  appear  anywhere  between  the  file  definition  and  end- 
of-job  statenent.  There  is  no  linit  on  the  nunber  of  VOTE 
statenents  which  nay  appear  in  a run. 


2.4  FS  Language 


i 2.4.1  Introduction 

The  standard  FS  language  discussed  in  this  section 
allows  the  user  to  define  additional  capabilities  not 
offered  with  the  coapatible  MIPS  1410  FPS  language.  inong 
these  are: 

a.  A naxinan  of  255  periodic  seta  nay  be  defined  for 
, a file  record. 

1 b.  More  than  one  variable  set  nay  be  defined.  (The 

sun  of  the  nunber  of  periodic  and  variable  sets  nay 
be  up  to  255.) 

c.  t variable  length  field  nay  be  defined  foe  each  set 
to  hold  coaaentary  data. 

d.  A subset  control  group  nay  be  defined.  one  or  nore 
fields  specified  at  the  beginning  of  a periodic  set 


22 


PILE  STRUCTURING  (PS) 


can  be  flagged  for  direct  subset  identification  in 
place  of  sequence  nuabers. 

e.  A total  of  100  fields  or  groups  aay  be  defined  for 
each  set. 

f.  A naxiaua  of  99  fields  aay  be  defined  as  a group. 

g.  A aaxiaua  of  50  groups  aay  be  defined  in  a set. 

h.  The  record  control  group  aay  be  as  large  as  244 
characters . 

i.  The  nuaber  of  subsets  per  set  is  a variable  and  is 
a function  of  the  available  coaputer  core  storage 
and  tbe  processing  function  requested.  No 
theoretical  liait  is  established  and  the  practical 
liait  is  large  in  coaparison  to  previous  systens. 

j.  Pields  and  groups  aay  be  specified  as  file  indexes. 
Any  field  not  variable  in  length  and  not  systea- 
generated  aay  be  specified  as  a secondary  index. 
Any  fixed-alpha  field,  variable  field,  or  variable 
set  aay  be  specified  as  a keyword  index.  Any 
fixed-alpha  field,  variable  field,  or  variable  set 
nay  be  specified  as  a keyword  index.  No  fixed 
field  aay  be  both  a secondary  and  keyword  index. 
There  aay  be  as  any  indexes  as  there  are  user- 
defined  fields  in  the  data  file. 


2.4.2  Language  Conventions 

The  standard  language  is  free  foraat  as  described  by  the 
* general  language  description  and  detailed  in  Voluae  I, 

Introduction  to  Pile  Concepts.  Text  strings  are  considered 
to  be  serial  strings  of  wards/characters  without  regard  to 
card  (record)  boundaries  and  aay  be  initiated  in  any 
character  position.  Rords  nay  not  be  split  between  cards 
(records) ; however,  any  nuaber  of  coaaas/blank s aay  be  used 
to  separate  words.  The  source  language  aay  be  in  either 
. card  or  sequential  data  set  fora.  OnL  y the  first  71 

characters  of  each  record  are  used.  However,  sequence 
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information  nay  be  provided  in  characters  73  through  80  and 
will  be  checked  by  the  nodule.  If  the  sequence  field 
indicates  a break  in  sequence,  an  advisory  message  will  be 
issued;  however,  structuring  will  still  be  perforaed.  The 
EBCDIC  collating  sequence  is  used  for  perforaing  the 
sequence  check;  all  cards  of  the  input  stream  including  and 
following  the  STRUCTURE  card  will  be  tested.  If  sequence 
checking  is  not  desired,  the  first  card  of  the  input  should 
contain  blanks  in  the  sequence  field. 

The  input  stream  is  nade  up  of  a series  of  statenents. 
By  definition,  each  statement  is  a series  of  words  or  terns 
initiated  by  an  operator  and  terminated  by  a period.  The 
sequence  of  the  statements  is  subject  to  general  rules  which 
are  provided  in  the  following  sections.  Each  statement  type 
is  discussed  in  the  sequence  of  its  occurrence  in  the  input 
strean. 


2.4.3  Language  Statements 


2. 4. 3.1  STRUCTURE  Statement 

This  statement  uses  the  operator  STRUCTURE  followed  by 
the  data  file  name.  This  statement  must  occur  first  in  the 
input  deck.  It  is  used  to  establish  the  name  of  the  file. 
File  names  conform  to  standard  system  naming  rules  as 
define!  in  volume  I,  Introduction  to  File  Concepts. 

Example: 

i 

STRUCTURE  SOPTEST. 


2.4.  3.2  SUB  Statement 

The  operator  SUB  ma y be  used  interchangeably  with  the 
ten  SUBROUTINE.  The  parameters  which  follow  the  operator 
must  be  ii  the  following  sequence: 
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a.  Subroutine  Naae  - Any  unique  naae  identifying  a 
user  subroutine;  follows  general  s yst  ea-na  aing 
conv  ent ion  s. 

b.  Punction  - Hay  be  input  or  output,  specifying  the 

use  of  the  subroutine  for  either  input  conversion 
or  output  conversion.  If  this  is  a subroutine  for 
a Secondary  Indexing  function,  CONVERT  or  ANALYZE 
■ ust  apoear  instead  of  INPUT  or  OUTPUT.  If  the 
subroutine  is  to  se  use!  for  ANALYZE  functions,  the 
following  length  and  node  entries  are  not  needed. 
For  all  other  functions  (input,  output,  and 

convert),  the  entries  aust  be  present. 

c.  Input  Length  - Deciwal  integer,  specifying  the 

length  of  the  input  data  field  to  be  processed  by 
the  subrou  tine . 

d.  output  Length  - Deciaal  integer,  specifying  the 

length  of  the  data  string  which  will  be  output  by 
the  subroutine. 

Input  Hode  - Hay  be  ALPHA,  DECIMAL,  COORD,  or 
BINARY  indicating  alphameric  (EBCDIC),  nuaecic, 
coordinate,  or  binary  nodes  of  operation.  This 
paraneter  identifies  the  node  of  the  input  to  the 
subroutine,  regardless  of  the  function  for  which 
the  subroutine  is  used.  See  subsection  2.3.2  of 
this  voluae. 

f.  Output  Mode  - sane  as  previous  paragraph,  where  the 
■ode  specified  applies  to  the  fora  of  output  froa 
the  subroutine,  regardless  of  the  function  for 
which  the  subroutine  is  used. 

Exaaples: 

SUB  SOBNAHE  INPUT  7 7 ALPHA  ALPHA. 

This  exaaple  indicates  a subroutine  naaed  SUBNAHE  which  is 
to  be  used  for  input  data  conversion.  The  length  of  the 
arguaeat  furnished  to  the  subroutine  is  to  be  seven 
characters  and  the  output  function  provided  by  the 
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subroutine  is  seven  characters.  The  aode  of  the  input  to 
the  subroutine  is  alpha  eerie  as  is  its  output  node. 

SUBROUTINE  CONVERT  OUTPUT  4 21  COORD  ALPHA. 

This  exaaple  indicates  a subroutine  naaed  CONVERT  which  is 
used  for  output  conversion.  It  expects  an  input  arguaent  of 
four  characters  (bytes)  a nd  will  provide  an  output  function 
of  21  alphameric  characters.  The  aode  of  the  input  arguaent 
is  the  special  systea  aode  of  coordinates,  discussed  under 
ths  FIELD  statement. 

SUB  SUB01  CONVERT  17  2 ALPHA  DECIMAL 

This  exaaple  indicates  a subroutine  naaed  SUB01  to  be  used 
to  convert  data  in  an  index  field  froa  its  file  foraat  to 
the  foraat  it  will  follow  in  the  Index  Data  Set  associated 
with  the  data  file.  It  expects  an  input  arguaent  of  17 
characters,  alphameric  aode,  and  will  provide  an  output  of 
two  deciaal  characters. 

SUBROUTINE  SUB 02  ANALYZE 

This  exaaple  indicates  a subroutine  naaed  SUB02  to  be  used 
to  analyze  the  paraaeter  list  of  the  FUNCTION  operator  to 
deter  nine  index  usage  and  to  provide  a list  of  values  for 
index  qualification. 


2. 4. 3. 2.1  SUB  Stateaent  for  Keyword  Usage 

The  SUB  statement,  when  used  to  define  subroutines  or 
i taoLes  applicable  to  keyword  indexing,  has  the  following 

paraaeters  following  the  operator: 

a.  Subroutine  Naae  - Any  unique  naae  identifying  a 
user  subroutine;  follows  general  systea-naaing 
conven  tions. 

b.  F unction  * Identifies  the  function  of  the  specified 
subroutine. 


♦ 
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STOP:  - Indicates  a table  containing  the  words 

that  are  to  be  eliiinated  froa  any 
further  keyword  processing. 

DICTIONARY  - Bay  also  be  specified  as  DICT.  This 
parameter  indicates  a table  containing 
all  values  that  are  acceptable  as 
keywords  for  the  fild. 

SCAN  - Indicates  this  user-provided  subroutine, 
rather  than  the  Systee  Scan  routine,  is 
to  be  indexed  to  process  and  extract 
keyword  candidates  f row  the  keyword  field 
in  the  transaction  record. 

E xaeples:  TAB  STOPNAB  STOP 

TAB  DICTNAB  DICTIONARY 

SOB  SCANNAB  SCAN 


2.4. 3.3  TAB  Statement 

Use  of  this  3tateeent  is  the  saee  as  for  the  SOB 
stateseit.  The  tere  TABLE  nay  also  be  used. 


2.4. 3.4  EDIT  Stateeent 

This  operator  identifies  an  edit  east  provided  by  the 
user.  The  foreat  of  the  stateeent  is  the  operator  followed 
by  a unique  naee  (within  this  file  and  follows  the  general 
systee  naie  rules)  and  the  user-supplied  edit  eask.  The 
■ask  is  delineated  by  single  quotation  earks  (5-8  punch), 
and  nay  contain  any  valid  edit  eask  characters  as  defined 
for  tie  NIPS  1410  PPS  systee  with  the  exception  of  the 
floating  dollar  sign  option,  the  debit  option,  the  sinus 
sign  left  option,  and  the  asterisk  protection  option.  An 
exaeple  of  this  stateeent  is: 

EDIT  EDNABE  '0.*  . 

This  stateeent  identifies  the  indicated  edit  eask  and  gives 
it  the  user-naee  EDNABE.  For  coding  rules  concerning 
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orsatioa  of  edit  aasks,  see  voluae  I,  Introduction  to  File 
Concepts. 


2.4.  3.5  CLASS  Statement 

The  operator  CLASS  for  this  stateaent  aay  be  substituted 
by  the  tera  CLASSIFICATION.  The  classification  label 
folic  us  and  is  enclosed  within  single  quotation  narks. 
Classification  labels  nay  not  exceed  32  characters. 

r xaipl  e: 

CLASSIFICATION  'TOP  SECRET'. 


2.4. 3.5  FIELD  Stateaent 

The  following  paraaeters  are  used  with  the 

FIELD  operator.  Where  sequence  is  critical,  appropriate 
notation  is  wade.  When  the  presence  or  absence  of  the 
operand  is  optional,  the  word  "Optional"  appears  in 
parenthesis  in  the  heading  for  the  description. 

a.  Field  Naae  - Ianediately  follows  the  operator;  aust 
be  a unique  naae  (for  the  file)  that  follows  the 
general  systea  naae  rules:  the  length  cannot  exceed 
seven  characters. 

b.  Field  Length  - Refers  to  the  EBCDIC  length  of  the 
data  field.  Where  NUHER  node  is  specified,  the 
actual  field  length  ay  differ  froa  the  specified 
field  length;  however,  this  adjustaent  is  internal 
to  the  systea  and  does  not  affect  the  specification 
in  the  FIELD  stateaent.  Typically,  this  length  is 
the  length  expected  in  the  input  transaction  or  the 
length  to  be  produced  by  the  systea  for  output 
purposes.  The  entry  is  coded  as  a n meric  integer, 
aot  to  exceed  three  characters  in  length.  High- 
order  zeros  aay  or  aay  not  be  included. 

c.  gqt/Fynction  Identifier  - Indicates  in  which  set 
the  field  is  to  be  structured.  Hay  be  the  single 
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alphabetic  character  I or  C,  indicating  fired  field 
or  record  control  field  respectively,  or  say  be  a 
nuaeric  integer  not  over  three  characters  in  length 
or  greater  than  255  in  value,  specifying  the 
periodic  set  to  which  the  field  is  to  be  assigned. 

Hay  also  contain  a single  alphabetic  character 
prefix  to  indicate  tha  following  capabilities: 

o "Cn",  where  "a"  is  any  integer  not  greater 

than  255.  Specifies  a subset  control  field  < 

for  the  "nth"  periodic  set.  This  capability 
is  to  be  jsed  when  the  analyst  desires  the 
subset  control  field  to  be  a data  field  of  the 
set,  rather  than  using  the  syst ew- supplied 
"PSSQ"  nuaber  for  subset  control. 

o "Vn",  where  "n"  is  subject  to  the  rules 
specified  above.  This  forn  indicates  the 
analyst  desires  the  field  to  be  defined  as  a 
variable  field.  "n"  again  specifies  the 
periodic  set  in  which  this  field  is  to  be 
structured. 

<*•  EisiiJ2ds_ijJs«ifieir_i2jti2a§tL  - Sequence  of  this 
and  all  following  PI  ELD  statement  operands  is  not 
critical.  Mode  specification  is  optional.  If  not 
provided,  the  systen  will  assune  ALPHA  node,  and 
issue  an  advisory  Message.  The  allowable  aodes  are 
ALPHA,  NO  HER,  and  COORD.  ALPHA  indicates  that  the 
data  field  content  is  to  be  alphaaeric  (EBCDIC) 
iaforaation  and  that  arithaetic  operations  against 
this  field  will  not  be  perforaed.  NO  HER  indicates 
that  the  data  field  content  is  to  be  considered 
nuaeric  data.  COORD  specifies  the  special  systea 
fora  for  geographic  coordinates.  This  data  is 
Maintained  by  the  systaa  in  internal  foraat  for 
processing  by  geographic  retrieval  techniques  and 
should  be  used  only  when  such  usage  is  expected. 

Mote  that  autoaat ic  conversion  of  input  and  output 
is  provided  by  the  systea  when  this  aode  is 
specified.  Allowable  input  foraats  to  this  field 
are  latitude  and  longitude  as  a single  field  or  as 
separate  fields  defined  as  a group.  output  foraats 
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produced  by  the  systea 
provided.  Note  that 
11,  and  15  characters 
■ ode  is  specified, 
indications  and  the 
voided . 


conversion  routines  are  al3o 
field  lengths  of  5,  6,  7,  8, 
are  permissible  when  this 
All  others  will  cause  error 
structuring  process  to  be 


HEat  _sa.J2L2.nLUe.  _Ue.LiLLLa.tk2n.  _JUtL2B.aU 

Subroutine  or  table  naae  required  for  autoaatic  1 

conversion  of  this  data  entry  should  be  included  in  j 

the  operand  string.  Note  that  this  naae  nust  be 

included  in  a subroutine  or  table  statement,  as  ] 

previously  discussed  in  sections  referring  to  SUB 

stateaents  and  TAB  stateaents.  The  function  (input 

or  output)  specified  in  the  subroutine  or  table 

statenent  is  assuned  and  cannot  be  overridden. 


f.  aa.tEji.t_ia.bLo  a.L  ia  § _ § E as  i £ is  at  ig  n_  lie  Lia  nail.  — sa»e 
as  input  subroutine  specification  above. 

g.  Edit  Hash  gpqcif icat^on  (Optional)  - Follows  the 
sane  rule  as  the  subroutine  specification.  The 
naae  provided  for  the  edit  nask  aust  be  defined  on 
an  edit  statenent,  as  previously  discussed  in  the 
section  under  EDIT  statenent;  this  will  cause  the 
aask  to  be  associated  with  the  field  for  output 
editing.  Note  that  both  output  subroutine 
processing  and  editing  say  be  specified. 

h.  iHkEHi  Title/Label  (Optional)  - The  user  aay 

include  an  output  title  or  label  to  be  associated 
with  the  field  when  it  is  output  under  the  QUIP 
coaponent.  Failure  to  include  thLs  operand  will 
cause  the  QUIP  coaponent  to  use  the  field  naae  for 
a title.  When  the  label  is  to  be  included  in  the 
FFT , it  i3  specified  by  delineating  the  desired 
"literal"  with  single  quotation  aarks  (5-8  punch). 

Exanples  of  FIELD  stateaents: 

FIELD  CFLDONE  5 X ALPHA  INSOB  OUTSUB  EDIT  1 
•CONTROL  FIELD  ONE*. 
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This  example  indicates  that  the  field  CFLDONE  is  to  be  five 
characters  in  length  and  a part  of  the  fixed  set  to  contain 
alphameric  data,  to  be  processed  on  input  by  the  SUB  named 
INSUB  (assumes  the  existence  of  SUB  statement),  to  be 
processed  on  output  by  the  subroutine  OUTSUB  (same 
assumption),  to  be  edited  on  output  by  the  edit  maslt 
specified  by  the  name  EDITl,  a n3  to  include  the  output  title 
or  label  CONTROL  FIELD  ONE.  Note  that  the  sequence  of 
oparanls  after  the  set  identifier  (X)  is  not  critical. 

FIELD  BAJBQPT  7 3 ALPHA. 

This  example  identifies  a request  for  a field  named  HAJEQPT 
which  is  to  be  seven  characters  long,  to  be  contained  in  the 
third  periodic  set,  and  to  be  alphameric  information.  No 
conversion  or  editing  has  been  requested,  and  no  output 
labal  was  provided.  Note  that  the  sequence  of  all  of  the 
terns  in  this  example  is  critical.  Actually,  ALPHA  is 
exempted  from  this  statement  and,  if  used,  the  node  must  not 
precede  the  set  identifier. 


2.4. 3.7  GROUP  Statement 

The  format  of  the  GROUP  statement  follows  a pattern 
similar  to  that  established  by  the  FIELD  statement. 
Following  the  GROJP  operator,  the  user- supplied  name  must  be 
found,  standard  system  naming  rules  apply  to  the  group 
naaa.  The  names  of  each  of  the  fields/groups  which  are  to 
be  included  in  this  group  definition  must  follow  the  group 
naaa.  Beyond  this  point  in  the  operand  string,  the  GROUP 
statement's  format  and  sequence  rules  are  exactly  the  sane 
as  those  for  the  FIELD  statement  beginning  with  the  rules 
for  mode  identification  of  the  FIELD  statement  description. 


2.4. 3.8  INDEX  Statement 

The  first  entry  must  be  INDEX.  Following  this,  the 
user-supplied  name  must  appear.  This  name  must  be  defined 
as  a field  or  group  by  an  appropriate  control  statement. 
Standard  system  naming  rules,  of  course,  apply.  Note:  No 
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field  or  group  longer  than  30  byte3  may  be  specified  as  an 
INDEX. 

The  following  parameters  apply  to  the  INDEX  statement. 
All  operands  are  optional.  Default  parameters  are  noted. 

a.  Index  Operand  - ADD  or  DELETE;  default  is  ADD. 
DELETE  is  used  to  delete  an  existing  index  during 
a OT  NDX3 PC  run.  It  is  of  no  consequence  daring  PS. 

&ilS-t°-Lndex_£ojive£§iaQ  _Sufe£2.j}£jji.e  _Se.£ci  fiction 
(Optional)  - The  subroutine  or  table  that  will  be 
invoked  for  autoati:  conversion  froa  data  file 
format  to  Index  Data  Set  format.  This  name  Bust  be 
specified  as  a conversion  routine  in  a SOB  or  TAB 
statement  as  described  in  section  2. 4. 3. 2.  If  no 
subroutine  is  specified,  values  wlLl  be  carried  in 
their  internal  data  file  format. 

C.  Iales_ia.aLXsii_Safc£0!iLia£-5Ea£itlsali2n  (Optional) 
The  subroutine  required  to  analyze  and  determine 
the  qualification  values  for  any  FUNCTION  operator 
in  which  the  indexed  field  or  group  is  a parameter. 
This  name  must  be  specified  as  an  analyzer 
subroutine  in  a SOB  or  TAB  statement  as  described 
in  section  2. 4. 3.2.  If  no  subroutine  is  specified, 
when  the  field  is  used  in  a FUNCTION  operator 
clause,  the  clause  will  be  bypassed  by  Index 
P rocessing . 

Txaiple  of  the  INDEX  statement: 

INDEX  CNTRY  ADD 

This  example  indicates  that  the  field  CNTRY  will  be 
designated  as  a file  index.  No  subroutine  will  be  used  to 
convert  data  from  the  file  format  to  a separate  index 
format.  Further,  no  analysis  of  a FUNCTION  operator 
parameter  list  in  which  this  field  appears  will  be  performed 
by  Index  Processing. 
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2. 4. 3. 9.1  IKDEX  Stateaent  for  Keyword  fields 

The  first  entry  Bust  be  INDEX.  following  this  the  user- 
supplied  naae  last  appear.  This  naaa  a ust  be  defined  as  a 
field  or  wariable  set  by  the  appropriate  control  3tateaent. 
Standard  systea  naaing  rules  apply.  A field  aay  not  be 
lefinel  as  both  a keyword  and  secondary  index. 

The  following  paraaeters  apply  to  the  INDEX  stateaent. 

a.  Index  Operand  - (ADD  or  DELETE)  - Default  is  ADD. 
DELETE  is  used  to  eliainate  an  existing  index  and 
is  used  only  by  the  index  specification  function 
perforaed  by  the  jtility  UTNDXSPC. 

b.  KEIWORD  - Designation  of  this  stateaent  as  one  that 
defines  a keyword  field  rather  than  the  standard 
secondary  index  field.  This  paraaeter  is  aandatory 
for  an  ADD  operation,  but  optional  for  a DELETE 
operation  as  the  field  has  already  been  designated 
as  a keyword  field. 


c.  Hyphen  Designation  - The  user  can  control 
processing  of  the  hyphen  by  the  systea  scan 
routine.  A hyphen  is  always  treated  as  a word 
separator  if  it  follows  a word  separator  character. 
If  it  is  followed  by  a text  character,  one  of  four 
options  can  be  applied.  TEXT  is  the  default  option 
which  weans  the  hyphen  is  to  be  treated  and 
retained  as  part  of  the  walue.  The  other  options 
are  DROP,  RETAIN  and  SEPARATE. 

DROP  - The  hyphen  is  either  superfluous  or  it 
is  a word  separator,  depending  upon  its 
context  with  respect  to  adjacent 
characters.  It  is  superfluous  if:  (1 ) 
text  characters  iaaediately  precede  and 
follow  it,  or  (2)  it  is  iaaediately 
preceded  by  a text  character.  In  this 
case,  blanks  are  considered  to  b* 
superfluous.  If  neither  of  these  cases 
apply,  the  hyphen  is  treated  as  a worl 
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separator.  In  any  rase,  the  hyphen  is 
dropped. 

RETAIN  - The  hyphen  is  subject  to  the  sane  rules 
as  the  DROP  option,  except  that  in  the 
two  cases  where  it  is  considered 
super f lions  it  is  retained  in  the  value 
as  a text  character. 

SEPARATE-  The  hyphen  is  always  treated  as  a word 
separator. 

d.  §.t22_Xifel£  " (Optional!  This  is  the  naae  of  the 

user  provided  table  that  is  to  be  applied  against 
the  values  in  this  field.  If  a value  is  found  in 
the  table,  it  is  to  be  eliminated  fro*  any  further 
consideration  as  a keyword.  If  a value  is  not 

present  in  the  table,  or  if  no  table  were 
specified,  the  value  becones  a keyword  candidate. 
This  table  nust  have  been  identified  by  a SUB/TAB 
statenent  and  have  been  defined  as  a STOP  table. 

3*  Pi ct lonac v - (Optional)  This  is  the  naae  of  the 

user  provided  table  containing  all  nonliteral 
values  fron  this  field  that  aay  becoae  keywords. 
This  table  nust  have  been  identified  by  a SOB/TAB 
statenent  and  have  been  defined  us  a DICTIONARY. 
If  no  dictionary  is  specified,  all  values  in  the 
field,  unless  sone  were  elininated  by  a Stop  Hord 
Table,  becone  keywords.  Literal  words  always 
becone  keywords. 

f.  5 can  S ubrout  jn$  - (Optional)  This  is  the  nane  of 
the  user  provided  subroutine  that  is  to  be  invoked 
to  process  the  keyword  field.  This  subroutine  nust 
lave  beea  identified  as  a SCAN  subroutine.  If  no 
subroutine  is  specified,  the  systea  *s  scan  routine 
will  select  the  keyword  candidates  fron  the  field. 
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Example: 

INDEX  VSET 1 ADD  KEYNOR D TAB1  TAB2. 

This  exaaple  indicates  the  field  naae  VSET1 , which  has 
already  been  defined  as  a variable  set,  is  to  be  a keyword 
inlax.  When  processing  this  field  in  the  transaction 
record,  TAB1,  defined  as  a stop  word  table  and  TAB2,  defined 
as  a dictionary  are  to  be  used  to  determine  what  values  are 
to  becoie  keywords. 


i 

t 

1 
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2.A.3.9  ? SET  Statement 

The  TSET  statement  defines  a variable  set  for  the  user's 
lata  fiLe.  More  than  one  variable  set  aay  be  defined  with 
a VSET  statement  supplied  for  each  one. 

Tha  operator  for  the  statement  is  the  tera  VSET  which 
appaars  first.  The  following  paraaeters  are  used: 

a.  Variable  Set  Ha  ee  - Bust  iaaediately  follow  the 
operator  and  is  unigue  for  the  file. 

b.  Variable  Set  Display  Size  - Daclaal  auaber  stating 
the  width  of  the  variable  set  to  be  printed  per 
Line  during  QUIP  processing. 

c.  - Label  of  up  to  6 9 
characters  in  length  aay  be  associated  with  the 
variable  set,  and  aust  be  enclosed  within  single 
guote  aarks. 


2.H.3.13  MOTE  Stateaent 

This  stateaent  provides  the  capability  to  have 
explanatory  coaaents  about  the  source  deck  recorded  on  the 
printout  produced  by  FS.  The  NOTE  operator  aust  occur  first 
in  the  stateaent.  The  inforaation  following  will  be  printed 
on  the  aource  printout  produced  by  FS.  No  periods  aay  be 
included  within  the  body  of  the  NOTE  stateaent,  since  such 
so  occurrence  would  signify  the  end  of  the  note.  Other  than 
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this  restriction,  all  other  valid  EBCDIC  characters  nay  be 
used.  The  MOTE  statement  aay  occur  anywhere  in  the  input 
streae  after  the  structure  statement  and  is  not  subject  to 
tbs  sequencing  rules  already  specified  or  those  discussed  in 
the  following  section. 


2.4.3.11  END  Statement 

Ths  last  stateaent  in  the  FS  source  deck  uses  the  single 
tera  END  or  ENDFS  to  signify  the  last  user-supplied 
stateaent. 


2.5  File  Structuring  for  a Non-NIPS  Pile 

FS  can  be  used  to  create  an  FFT  which  describes  all  the 
usable  data  elenents  of  a non-NIPS  data  file.  This 
description  includes  the  definition  of  various  record 
fonats,  record  type  fields  used  to  identify  the  different 
record  fornats,  record  ID  fields,  and  FILLER  fields  to 
account  for  eleaents  within  a record  foreat  to  be  ignored. 


2.5.1  General  Considerations 

In  describing  a non-NIPS  file  via  FS,  the  file  aust 
confora  to  various  constraints  and  restrictions.  These  deal 
viti  jaaeral  file  organization,  logical  record  size,  record 
type  fields,  record  ID  fields,  complete  foraat  description 
and  data  content. 


2.5. 1.1  File  Organization 

To  be  described  by  FS,  a non-NIPS  file  wust  contain 
either  fixed  length  or  variable  length  records.  Fixed 
length  records  can  be  up  to  996  bytes  in  length.  Variable 
lenjth  records  can  be  up  to  1,000  bytes,  but  the  first  four 
bytes  Must  contain  the  length  at  the  record.  The  records  in 
the  file  say  be  either  blocked  or  unblocked. 
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2.5.  1.2  Record  Foraats 

Th  2 records  within  a non -NIPS  file  nay  have  nany 

different  fornats.  Up  to  256  different  foraats  aay  be 
contained  with  a single  file.  Bach  foraat  aust  be 
identified  by  a single  record  type  field.  This  field  aust 

be  present  in  all  records,  have  the  saae  location  in  all 

records,  and  have  the  sane  length  in  all  records  (up  to  10 
bytes) . 

3 f the  possible  256  different  record  foraats,  one  nu3t 
be  identified  as  a nonrepeating  (fixed)  foraat.  This  foraat 
will  be  treated  like  the  fixed  set  in  a NIPS  record  and  it 
aust  be  present  for  each  unique  record  ID.  Only  one 

occurrence  of  the  nonrepeating  foraat  is  peraitted  within  a 
record  ID.  All  other  fornts  are  considered  to  be  repeating 
fornats  and  will  be  treated  as  periodic  sets  in  a NIPS 
record.  Their  presence  is  optional  within  a record  ID. 

(then  describing  the  foraat  of  a record  type,  each  byte 
Ln  the  record  au3t  be  incladed  in  a field  definition.  These 
include  data  fields  which  are  not  relevant  to  query 
reguiraaents  and  various  systea  fields  such  as  the  record 
length  field.  Pields  which  are  to  be  ignored  can  be 
designated  by  the  special,  repeatable  field  naae  FILLER. 
FILLER  fields  cannot  be  referenced  beyond  definition. 


2.5.  1.3  Record  ID  Fields 

Eaci  record  au3t  have  record  identification  data  which 
is  contained  in  one  or  sore  user  designated  fields.  These 
fields  need  not  be  contiguous;  but  each  field  aust  be 
| present  Ln  each  record.  The  field  positions  aay  differ 

i between  record  types,  but  the  field  size  and  its  relative 

position  in  the  record  ID  aust  not  differ.  The  length  of 
the  record  ID  cannot  exceed  256  bytes. 


2.5.  1.4  Data  Field  Restrictions 

Data  fields  will  be  processed  as  either  alphabetic, 
nuaeric,  or  coordinate;  however,  nuaeric  and  coordinate  node 
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fislis  mst  adhere  to  certain  restrictions.  To  be  processed 
as  nueeric,  a data  field  must  be  either  a binary  fullword  or 
a zoned  decieal  field.  All  other  nueeric  data  fields  (non- 
fullword  binary,  floating  point,  and  packed  decieal)  east  be 
defined  as  alpha  and  have  an  associated  subroutine  to 
provide  output  translation. 

Data  fields  which  are  defined  as  coordinate  must  confore 
to  the  standard  NIPS  coordinate  data  field  foraat.  The  data 
eust  be  in  binary  word  foraat,  a fullword  each  for  latitude 
and  longitude,  and  eust  be  translatable  by  the  NIPS 
coordinate  subroutines  into  a standard  external  11  or  15 
character  geographic  coordinate.  Otherwise,  the  field  east 
be  defined  as  alpha. 

A single  variable  length  data  field  way  be  defined  for 
each  record  type  provided  the  field  is  the  Last  field  in  the 
record  type.  Also  the  record  type  eust  include  a fullword 
binary  field  containing  the  length  of  the  variable  field. 


2.5.2  Language  Statements 


2. 5. 2.1  STRUCTURE  Statement 

The  STRUCTURE  statement,  in  addition  to  defining  the 
file  naae,  will  initiate  creation  of  a non-NIPS  FPT,  when 
the  keyword  NONIPS  follows  the  file  nane.  The  file  naae 
must  still  conform  to  all  standard  NIPS  conventions. 

rxampl  e: 

STPUCTUFE  NNTEST  NONNIPS. 


2.5.  2.2  DEFINE  St  at  emen*- 

The  DEFINE  is  used  to  define  the  beginning  of  a new 
record  type  and  must  preceed  all  FIELD/GROUP  statements  for 
tha  record  type.  The  parameters  which  follow  the  operator 
must  be  in  the  following  sequence: 


PILE  STRUCTURING  (PS) 


I 

i 


i 


a.  Record  type  sequence  number  - Either  an  "X"  for  the 

first  record  type  defined  or  a one-up  sequence 
numbs:  for  each  additional  record  type  (1  through 

255).  An  "X"  denotes  that  the  record  type  is  non- 
repeating. The  nonrepeating  record  type  must  be 
the  first  record  type  defined. 

b.  Record  type  qpflf  - The  value  with  a record  which 
will  uniquely  identify  the  record  type.  The  code 
■ ay  be  from  1 through  10  characters  in  length  and 
■ay  be  expressed  in  either  character  or  hexadecimal 
representation.  For  character  representation,  the 
code  i3  entered  as  alphanumeric  characters, 
enclosed  in  singla  quotas  if  any  special  characters 
are  used.  Embedded  single  quotes  are  not 
permitted.  For  hexadecimal  representation,  the 
code  i3  entered  in  hexadecimal  notation,  enclosed 
in  single  quotes,  and  preceded  with  an  I.  The 
code,  in  hexadecimal,  may  represent  a maximum  of  10 
bytes. 

Bxample  using  character  representation: 

DEFINE  X ABC9. 

DEFINE  1 '7 1*2  * . 

Example  using  hexadecimal  representation: 

DEFINE  2 X'FI E4FF40* . 

NOTE:  The  DEFINE  statement  is  not  permitted  when 
structuring  a standard  NIPS  FFT. 


2.  5.  2.  3 FIELD  Statement 

The  FIELD  statement  is  used  to  describe  each  field  in 
the  non-NIPS  file.  The  following  parameters  are  used 
following  the  FIELD  operator: 

a.  * Immediately  follows  the 

operator.  Any  name  conforming  to  the  standard  NIPS 
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naaing  conventions  can  be  used  wi  th  the  following 

restrict  ions  : 

1.  FILLER  is  tha  naaa  used  to  account  for 

unneeded  or  unused  bytes  within  a record  type. 

2.  vsza  is  the  nane  used  to  reference  a binary 
full  word  field  which  contains  the  length  value 
for  the  variable  field  in  the  record  type.  In 
the  nane  VSZn,  "n"  is  oaitted  when  referenced 
in  the  nonrepeating  record  type  and  "n  " is  the 
record  type  sequence  nuaber  when  referenced  in 
a repeating  record  type. 

3.  When  the  nane  is  applied  to  a record  ID  field, 

the  naae  aust  be  duplicated  for  the 

redefinition  of  the  field  in  each  record  type, 
when  the  naae  is  applied  to  the  record  type 
field,  the  naae  Bayba  duplicated  for  each 
record  type.  In  this  case,  any  reference  in 
QUIP  to  the  field  naae  will  apply  to  the  fixed 
r ecoc  d type  only . 

Ei£ld_L§aat£_il£aail£iL  - The  length  of  the  field 
t with  the  following  considerations: 

1.  Record  ID  fields  - The  length  aust  be  the  saae 
for  all  occurrences  of  the  saae  record  ID 
field  naae. 

2.  Record  type  field  - The  length  can  be  a 

i aaxiaua  of  ten  bytes  and  aust  reaain  constant 

for  each  redefinition  of  the  field.  The 
leigth  aust  be  sufficient  to  contain  the 
’ record  type  coda  entered  on  the  preceding 

DEFINE  stateaent. 

3.  NUHEF.  fields  - The  length  is  the  nuaber  of 

positions  to  be  output.  The  internal  length 

is  assuaed  to  be  four  bytes  an  a full  word 
boundary  unless  the  field  is  contained  in  a 
group;  then  the  internal  length  is  the  saae  as 
the  output  length. 
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4.  COORD  fields  - The  output  length  of  the 
coordinate  field.  Acceptable  lengths  are 
5,6,7,8,11  and  15.  The  internal  length  is 
assuaed  to  be  four  bytes  if  the  output  length 
is  less  than  11  or  eight  bytes  if  the  output 
length  is  greater  than  8.  Internal,  the  field 
is  assuaed  to  be  on  a full  word  boundary. 

5.  ALPHA,  DECHL  and  FILLER  fields  - The  length  is 
the  nuaber  of  bytes  contained  in  the  field  in 
the  file. 


s et^iiflCt  UfiSUUfidL  - The  set 

seguence  nuaber  froa  the  preseeding  DEFINE 
stateaent  or  one  of  tbs  following  codes  for  special 
functional  use: 

1.  "Cn"  is  used  to  identify  the  field  as  a 

portion  of  the  record  ID.  The  "n"  is  a 1-  to 
3-digit  nuaber  denoting  the  fields  relative 
position  in  the  ID.  When  used  on  a 

redefinition  of  a record  ID  field,  the  "Cn" 
value  aust  bs  the  saae  as  on  the  original 
definition. 

2.  "T"  is  used  to  identify  the  field  as  the 
record  type  field.  This  field  will  contain 
the  record  type  code  as  specified  on  the 
preceding  DEFINE  stateaent. 

3.  "Vn"  is  used  to  identify  the  field  as  a 

variable  field.  The  "n"  is  the  set  sequence 
nuaber  froa  the  preceding  DEFINE  stateaent. 
A field  identified  as  a variable  field  aust 
have  an  associated  "VSZn"  field  and  aust  be 
the  last  field  defined  in  the  record  type 
description. 

Field  node  Identifier (0 Ptiona  11  - If  specified, 

this  is  the  node  of  the  field.  Valid  entries  are: 


1.  ALPHA,  used  to  identify  the  field  as 
containing  either  alphanuaeric  data  or 
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noostandacd  numeric  data.  nonstandard 

numeric  data  includes  packed  decimal  fields 
and  binary  fields  which  are  not  fullvords.  Mo 
arithmetic  operations  are  permitted  against 
ALPHA  fields.  ALPHA  is  the  only  valid  node 
for  record  ID  and  record  type  fields. 

2.  NUMER  , used  to  identify  the  fields  as 

containing  standard  numeric  data.  The  data  < 

will  be  assumed  to  be  fullvord  binary  unless 

the  field  is  contained  in  a group,  in  which 

case  it  will  be  assumed  to  be  zoned  decimal 

(EBCDIC). 

3.  DE. HL , used  to  identify  the  field  as 

containing  coned  decimal  numeric  data.  Thi3 
mode  is  not  permitted  when  executing  a 
standard  MIPS  Pile  Structure. 

4.  COORD,  used  to  identify  the  field  as 

containing  coordinate  data  in  the  standard 
internal  HIPS  binary  word  format. 

3th ec  Operands  - Additional  operands  which  may  be 
specified  are: 

1.  Input  Subroutine  Specification 

2.  Output  Subroutine  Specification 

3.  Edit  Mask  Specification 

4.  output  Title /Label 


The  uses  of  these  operands  is  the  sane  as  when 
specified  for  a standard  MIPS  FS  and  art  described 
in  section  2. 4. 3. 6. 
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2.5. 2.4  GROUP  Statement 

The  GROUP  statement  is  used  to  identify  a sequence  of 
adjacent  field/groups  to  ba  collec  ti  vel  y refer  en  ced  via  a 
new  naaa.  The  rules  which  apply  to  defining  a group  for 
standard  NIPS  files  also  apply  for  non-NIPS  files  as 
described  in  sections  2.3.6  and  2. 4. 3. 7. 

When  defining  a group  f or  a non-NIPS  file,  the  group 
cannot  contain  any  FILLER  fields,  nor  can  it  be  naned  < 

FILLER.  Additionally,  no  fullword  binary  fields  can  be 
included  in  a group. 


2.5. 2.5  Other  FS  Statements 

Tha  INDEX  and  VSET  statements  are  not  allowed  for  non- 
NIPS  files.  The  SOB,  TAB,  EDIT,  CLASS,  NOTE  and  END 
statements  are  used  in  the  same  manner  as  for  standard  NIPS 
files. 
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Section  3 


OUTPUT 


output  from  the  file  structuring  prograa  consists  of  a 
listing  of  the  input  deck  with  aessages  noting  any  diagnosed 
errors.  5o«e  aessages  are  only  advisory,  but  aost  of  thea 
relate  to  errors  which  prevent  the  structuring  of  the  PFT  * 
If  the  PFT  is  successfully  structured,  it  is  printed  out 
ianediately  following  the  deck  listing  and  the  individual 
records  which  aake  up  the  PFT  are  written  oa  the  direct 
access  device  saved  for  file  generation.  The  newly 
structured  PFT  can  be  contained  in  an  Indexed  Sequential 
Access  Method  (15  AN)  or  a Virtual  Storage  Access  Method 
( VSA “ ) data  set  as  detailed  in  Voluae  VIII,  Job  Preparation 
Manual.  At  that  tine  the  actual  data  records  are  created 
and  wiLL  reside  with  the  PFT  on  the  sane  voluae.  During 
file  structuring,  the  user  has  the  option  of  specifying  a 
file  block  size  greater  than  1,004.  If  he  does  not  specify 
a block  size,  file  structuring  will  U9e  the  standard  1,004 
size.  Details  for  block  size  specifications  can  be  found  in 
Volume  VIII,  Job  Preparation  Manual. 


3.1  Error  and  Exception  Detection 

Soie  errors  dee  abort  ire  in  constructing  an  PFT,  while 
o'hers  are  nerely  advisory  in  nature.  All  errors  are  listed 

on  the  systea  output  device  as  they  are  discovered  in  each  { 

iipu*  card  subaitted.  At  the  end  of  a job,  the  PFT  is 

constructed  if  no  abortive  errors  were  found  during  the  i 

processing  of  the  input  deck. 


3.2  Operation  for  the  Pile  Structure  Coaponent 

This  subsection  contains  a brief  flowchart  of  the 
operations  perforaed  by  PPTs  during  execution. 
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3.3  Sanple  Pile  Structure  Job 

contained  in  this  subsection  is  a listing  of  both  the  os 
job  control  language  statements  and  the  file  structure 
source  leek  (standard  language)  used  to  structure  the  sample 
file  presented  in  Volume  I,  Introduction  to  File  Concepts. 


//FS  ^60  JOB 
// 

// 

//FS. SYSIN 
STRUCTURE 

classifica  t: 


(Standard  Parameters) 

EXEC  XFS,  ISM  =TBST360  ,N  DISP*CAT  LG  , 

VI S AH=  *SER=DA0001',LIB=TEST360 
DD  * 

T S3  r 3 60  . 

ON  'UNCLASSIFIED' 


NOTE 

NOTE 


NOTE 

TABLF 

TABLE 


FILE  NAME-  TEST36D. 

FILE  CONTENTS-  HYPOTHETICAL  DATA  FILE  pOR  TRAINING  AND 
TESTING  PURPOSES-  THE  DATA  FILE  CONTAINS  PSEUDO  DATA  RELATING 
TO  THE  POSTURE,  ORGANIZATION,  LOCATION,  COWHAND,  EQUIPMENT, 
AND  PLANNED  UTILIZATION  OF  COH  BAT  UNITS  OF  TH?  ARHED  FORCES. 

THE  FOLLOWING  SUBROUTINES  AND  TABLES  APE  USED  FOR  DATA 
CONVERSION. 


KEYSTOP 

ACCEPT 


STOP. 

EICT  IONARY, 


TABL  E 

RCHDS 

INPUT 

6 

1 

ALPHA 

ALPHA. 

j SUBROUTINE 

DTGIS 

INPUT 

12 

10 

ALPHA 

ALPHA. 

TABL  E 

OCM5S 

OUTPUT 

1 

6 

ALPHA 

ALPHA. 

j TABLE 

CTPrS 

OUTPUT 

2 

15 

ALPHA 

ALPHA. 

TABLE 

ACT  VS 

OUTPUT 

2 

15 

ALPHA 

ALPHA. 

TABLE 

UNLVS 

OUTPUT 

3 

15 

ALPHA 

ALPHA. 

SUBROUTINE 

DTGOS 

OUTPUT 

10 

12 

ALPHA 

ALPHA. 

NOTE  THE 

FOLLOWING  EDIT 

H ASKS 

ARE  USED  DURING 

ED  IT 

EDIT 

EDIT 

NOTE 

FIELD 

FIELD 

GROUP 

NOTE 

GROUP 


OUTPUT  PROCESSING 
TO  SUPPRESS  LEADING  ZEROS  AND  SUPPLY  DECIMAL  POINTS  FOR 
NUHEPIC  VALUES. 

HOOl  'Kj)H)IO)('. 

HOD  2 •*.!»)«'. 

MOD  3 

THE  FOLLOWING  ELEMENTS  ARE  USED  FOR 
SEPV  1C  ALPHA  RCHDS  OCHDS 

UUIN  5 C ALPHA 

UIC  S ERV  , U U IN  ALPHA 
THE  FOLLOWING  TWO  GROUP  ST  AT  B)  EN  TS 


RECORD  CONTROL. 

• SER  VICE  BRANCH* . 
•UNIT  IDENTIFIER*. 

• UNIT  ID  CODE* . 

ARE  USED  TO  REDEFINE 


THE  CONTROL  GROUP  -UIC-  WITH  TWO  ADDITIONAL  NAHES. 
PECID  SEPV, UUIN  ALPHA  'RECORD  CONTROL* 
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GR  ) UP 

CONTROL  SERV 

, UUI  N ALPH  A 

•RECORD  CONTROL'  . 

NOTE 

THE  FOLLOWING  EL  B!  ENTS 

ARE  CONTAINED 

IN  THE  PIXED  SET  OP 

THE  DAT* 

RECORD. 

FIELD 

UNTTT 

4 

X 

ALPHA 

•U  NIT  TY  PE  CODE'  . 

PIELD 

UNTYZ 

1 

X 

ALPHA 

•HAJOR  UNIT  INDICATOR*. 

PIELD 

UNLVL 

3 

X 

ALPHA 

UNLVS 

•HAJCR  CRG  LEVEL' . 

GROUP 

UNTLV 

UNTYY, 

UNTYZ, UNLVL 

•UNIT  TYPE  AND  LEVEL'. 

PIELD 

HOHE 

1 

X 

ALPHA 

RCHDS 

DCHDS 

•HOHE  COHH AND' . 

PIELD 

UNPLG 

1 

X 

ALPHA 

•UNIT  FLAG'. 

PIELD 

HJFOR 

1 

X 

ALPHA 

•HAJCR  FORCE  IND.'  . 

PIELD 

PREV 

1 

X 

ALPHA 

RCHDS 

DCHDS 

•PREVIOUS  COHHAND ' . 

PIELD 

AT  ACH 

1 

X 

ALPHA 

R Q1  DS 

DCHDS 

• ATTACHED  COHHAND' . 

PIELD 

PUTU 

1 

X 

ALPHA 

RCHDS 

DCHDS 

• PUTUR  E COHHAND*  . 

PIELD 

TRDTG 

1 0 

X 

ALPHA 

DTGIS 

DTGOS 

•TRANSFER  DATE'. 

FIELD 

UNRDT 

2 

X 

ALPHA 

•READINESS  STATUS*  . 

PIELD 

RE  AS  N 

1 

X 

ALPHA 

•REASON'. 

PIELD 

R ATTN 

2 

X 

ALPHA 

•ATTAINABLE  STATUS*. 

GROUP 

RECDE 

UNRDY, 

RE  AS  N,  RATTN 

•READINESS  GROUP'. 

PIELD 

R A DTG 

10 

X 

ALPHA 

DTGIS 

DTGOS 

•ATTAIN.  STATUS  DTG'. 

PIELD 

UNIT 

12 

X 

ALPHA 

• UNIT  NAHE- SHORT' . 

PIELD 

U NAME 

27 

X 

ALPH  A 

• UNIT  NAHE-FULL* . 

PIELD 

OPCON 

6 

X 

ALPHA 

•OP  CONTROL  UNIT'  . 

PIELD 

COHDR 

20 

X 

ALPHA 

•CO  NAHE  AND  RANK* . 

PIELD 

LOC 

1 8 

X 

ALPHA 

•LOCATION  NAHE*. 

PIELD 

POINT 

11 

X 

OOORD 

•HQ  COORD  LOCATION'. 

PIELD 

DAPT1 

1 1 

X 

COORD 

•DUTY  AREA  POINT  1*. 

PIELD 

DAPT2 

1 1 

X 

COORD 

•DUTY  AREA  POINT  2'. 

PIELD 

DAPT3 

11 

X 

COORD 

•DUTY  AREA  POINT  3*. 

PIELD 

DAPT4 

1 1 

X 

COORD 

•DUTY  AREA  POINT  4*. 

GROUP 

AREA  DAPTl,DAPT2 

,D  APT3 , 

DAPT4 

COORD 

•GEO-DUTY  AREA'. 

PIELD 

CNTRY 

2 

X 

ALPHA 

CTRYS 

•COUNTRY  CODE*  . 

PIELD 

CNAH 

15 

X 

ALPHA 

•COUNTRY  NAHE'. 

PIELD 

GEPOL 

2 

X 

ALPHA 

CTRYS 

•GEOPOLITICAL  AREA'. 

PIELD 

PERS 

6 

X 

NU  HER 

HOD1 

•AUTHORIZED  PER  SNL* . 

FIELD 

ACTIf 

2 

X 

ALPHA 

ACT  VS 

•CURRENT  ACTIVITY'. 

PIELD 

LAUD 

10 

X 

ALPHA 

•DTG  LAST  UPDATE'  . 

PIELD 

LYN 

1 

X 

ALPHA 

•LOCATION  STATUS' . 

PIELD 

R PER  S 

1 

X 

NUHER 

• PERSNL  READINESS'. 

PIELD 

RS  PLY 

1 

I 

NO  HER 

•SUPPLY  READINESS*. 

PIELD 

REQPT 

1 

X 

NUHER 

• EQU  IP  HE  NT  READINESS*. 

PIELD 

RTRNG 

1 

X 

NUHER 

•TRAINING  READINESS'. 

GROUP 

RHGRP 

RPERS, 

RSPLY, REQPT 

, RTRNG 

NUHER 

•READY  GROUP*. 

FIELD 

READAYG  3 

I 

NUHER 

HOD2 

•READINESS  AVERAGE'. 

1 

n 
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FIELD 

R ITNH 

3 

X 

HU  HER 

HOD3 

•RADIUS-RAT 

. BILES 

FIELD 

UHTYP 

5 

X 

ALPHA 

•UNIT  TTPE 

CODE*  . 

FIELD 

TPNAH 

42 

X 

ALPHA 

•UNIT  TTPE 

RAflE*  . 

FIELD 

UNTOE 

17 

X 

ALPHA 

•Y/O  AND  E 

REF.  •. 

FIELD 

HIER 

11 

X 

ALPHA 

•HIERARCHY 

CODE*  . 

FIELD 

COHHENT 

50 

?x 

ALPHA 

•COHHENT*  . 

NOTE  THE 

FOLLOWIN 

3 ELEMENTS  ARE 

USED  FOR 

PERIODIC  SET  1 

CONTROL 

FIELD 

HECL 

3 

Cl 

ALPHA 

•HAJOR  EQP. 

CLASS' 

FIELD 

HEQPT 

10 

Cl 

ALPHA 

•HAJOR  EQP. 

ID*  . 

GR  ) UP 

HECLQ  HE 

IL,  HEQPT 

•EQP.  CLASS 

AND  TY1 

NOTE  THE  FOLLOW  ING  EL Ed  BITS  AR E CONTA IE  ED  IN  PERIODIC  SET  1 OF  THE 
DATA  RECORD. 


FIELD 

HEHOD 

10 

1 

ALPHA 

•HAJOR  EQP.  MODEL*. 

FIFLD 

HENAH 

18 

1 

ALPHA 

•MAJOR  EQP.  RARE*. 

FIELD 

HEPCAP 

1 

1 

ALPHA 

•WEAPON  DEL.  TYPE*. 

FIEL  D 

HEPSD 

3 

1 

NUHER 

•NUMBER  POSSESSED'. 

FIFLD 

HEADA 

3 

1 

NUHER 

•NUHBER  ON  ALERT'. 

FIELD 

HEOPC 

3 

1 

NUHER 

•NO.  CONYEN.  OP  READY*. 

FIELD 

HEORN 

3 

1 

NUHER 

•NO.  NUCLEAR  OP  READY'. 

FIELD 

HESQP 

3 

1 

NUHER 

•NO.  SPEC.  ALERT  EQPS*  . 

FIELD 

HESWP 

3 

1 

NUHER 

•NO.  SPEC.  ALERT  WPNS'. 

GROUP 

HESIA 

HESQP 

.HESWP  NUHER 

•SPEC.  ALERT  TALLY'. 

FIELD 

HESIC 

3 

1 

NUHER 

•NO.  SPEC.  COMMITTED*. 

FIELD 

HEPEC 

1 0 

1 

ALPHA 

•RECONN.  CAPABILITY*. 

FIELD 

HBDEP 

1 

1 

ALPHA 

•DEPLOYMENT  ID*. 

FIELD 

HEDDT 

5 

1 

NUHER 

•DEPLOYMENT  DATE'. 

FIELD 

HEDUR 

1 

1 

ALPHA 

•DEPLOYMENT  TIME  CODE*. 

FIELD 

HELYN 

1 

1 

ALPHA 

•DEPLOY.  LOC.  STATUS'. 

FIELT 

HELOC 

18 

1 

AL  PH  A 

•DEPLOYMENT  LOCATION*. 

FIELD 

1BPNT 

11 

1 

COORD 

'DEPLOYMENT  COORD*. 

FIELD 

HETR  Y 

2 

1 

ALPHA 

CTRYS 

•DEPLOY.  COCNTRY  CODE*. 

FIELD 

HEPOL 

2 

1 

ALPHA 

CTRYS 

•DEPLOY.  GEOPOLITICAL'. 

FIELD 

HECNA 

15 

1 

ALPHA 

•DEPLOYMENTS  COUNTRT*  . 

NOTE 

THE  FOLLOWING 

ELEMENTS  ARE 

CONTAINED 

IN  PERIODIC  SET  2 OF  THE 

DATA 

RECORD. 

FIELD 

SECLASS 

3 

2 

ALPHA 

•SECONDARY  EQP  CLASS*. 

FIELD 

SEHODEL 

10 

2 

ALPHA 

•SECONDARY  EQP  MODEL*. 

FIELD 

S SNARE 

18 

2 

ALPHA 

•SECONDARY  EQP  NAME*. 

FIEL  D 

SEPOSSD 

4 

2 

NUHER 

•SECONDARY  EQP  POSS.*  . 

FIELD 

SEAUTH 

4 

2 

NUHER 

•SECONDARY  EQP  AUTH.*. 

NOTE 

THE  FOLLOWING 

ELEMENTS  ARE 

CONTAINED 

IN  PERIODIC  SET  3 OF  THE 

DATA 

RECORD. 

FIELD 

PLAN 

4 

3 

NUHER 

'PLAN  ID*. 
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FIELD 

PLEAC 

1 

3 

ALPHA 

•PLAN  STATUS*. 

PIELD 

PLDTG 

1 0 

3 

ALPHA  DTGIS  DTGOS 

•PLAN  STATUS*. 

FIELD 

PLPST 

1 

3 

ALPHA 

•DTG  AVAILABLE'. 

PIELD 

PLFDG 

1 

3 

ALPHA 

•EXPECTED  PLAN  STATUS*. 

PIELD 

PLRT 

6 

3 

ALPHA 

•P  LAN  RES  PONSE  TIME*  . 

PIELD 

PLT  RT 

6 

3 

ALPHA 

• STAGING  TIME'  . 

NOTE 

THE  POLLOWING 

ELEMENT  IS  CONTAINED  IN 

PERIODIC  SET  4 OP  THE 

DATA  RECORD. 

PIELD 

T RT  Y 

6 

4 

ALPHA 

•TREATY  NAME*. 

NOTE 

THE  POLLONING 

ELEMENTS  ARE 

CONTAINED 

IN  PERIODIC  SET  5 OF  THE 

DATA  RECORD. 

PIELD 

NAME 

18 

5 

ALPHA 

•NAME'  . 

PIELD 

RANK 

4 

5 

ALPHA 

•RANK' . 

PIELD 

SERNONR 

6 

5 

ALPHA 

•SERIAL  NUMBER'  . 

PIELD 

SERVICE  1 

5 

ALPHA 

• SER  VICE'  . 

PIELD 

ASSGN 

20 

5 

ALPHA 

•DUTY  ASSIGNMENT'. 

PIELD 

SPCODB 

5 

5 

ALPHA 

•SPECIALITY  CODE* . 

NOTE 

THE  POLLOWING 

ELEMENTS  ARE 

CONTAINED 

IN  PERIODIC  SET  6 OF  THE 

DATA  RECORD. 

PIELD 

SBUIC 

6 

6 

ALPHA 

•SUBORDINATE  UNIT  UIC*. 

PIELD 

SBPLG 

6 

6 

ALPHA 

•SUBORD.  UNIT  FLAG*. 

ROTE 

THE  POLLONING 

ELEMENT  IS  CONTAINED  IN 

A VARIABLE  SET  OP  THE 

DATA  RECORD. 

INDEX 

COMMENT  ADD 

KEYWORD. 

INDEX 

REFER 

ADD 

KEYWORD 

KEYSTDP 

ACCEPT. 

VSET 

REFER 

50 

•UNIT  REMARKS'. 

INDEX 

SERV 

ADD. 

INDEX 

CNTRY 

ADD. 

INDEX 

BEDDT 

ADD  . 

INDEX 

HETRY 

ADD. 

INDEX 

PLRT 

ADD  . 

INDEX 

END. 

5 PCODE 

ADD. 
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3.4  Saaple  Non-NIPS  PS  Job 

Contained  in  this  subsection  is  a listing  of  both  the  05 
job  control  language  statenents  and  the  file  structure 
source  deck  used  to  structure  a saaple  non-NIPS  PFT. 

//FSNNJOB  JOB  (Standard  paraaeters) 

//  EXEC  IPS, 

//  ISAH  = 'NN.TEST360.PFT'#¥ISAB*  'SER*DA0001  • , 

//  PRIHB=  1,  NDIS  P*CATLG,  LIB=TIST360 

//FS.SYSIN  DD  * 

STRUCTURE  FPT  NONNIPS. 

MOTE  — THIS  FPT  IS  DESIS NED  POR  OSB  WITH  A NON-NIPS  VERSION  OP  THE 
TEST360  PILE  S HON N IM  PART  3-3  OP  THIS  VOLUME. 
CLASSIFICATION  UNCLASSIFIED. 

MOTE  — EACH  RECORD  TYPE  (SET)  BUST  BEGIN  WITH  A DEPINE  STATEMENT. 


NOTE  — 

DEFINE  RECORD  TYPE  TO  ACT  AS  FIXED  SET. 

DEFINE 

r.  * a • . 

NOTE  — 

NEXT 

FIELD  IS  FOP  SPACING  - NOT 

ADDRESSABLE 

FIELD 

FILLER 

2 X 

ALPHA 

MOTE  ~ 

DEFINE  RECORD  ID 

FIELDS. 

FIELD 

SERV 

1 Cl 

ALPHA  'RECORD 

ID-  PART  1*. 

PIELP 

UUIN 

5 C2 

ALPHA  'RECORD 

ID-  PAST  2 ' . 

GROUP 

UIC 

SEP  ¥ UUIN 

ALPHA  • RECORD 

ID-  GROUP'. 

NOTE  — 

NEXT 

FIELD  IS  FOP  SPACING  - NOT 

ADDRESSABLE 

FIELD 

PILLER 

2 X 

ALPHA. 

NOTE  — 

DEFINE  RECORD  TYPE  FI  EL  D. 

FIELD 

R TYPE 

1 T 

ALPHA. 

FIELD 

HOME 

1 X 

ALPHA. 

FIELD 

HJFOR 

1 X 

ALPHA. 

FIELD 

ATACH 

1 X 

ALPHA. 

FIELD 

TRDTG 

1 0 X 

ALPHA. 

FIFLP 

UNRDY 

2 X 

ALPHA. 

FIELD 

REASN 

1 X 

ALPHA. 

FIELD 

RATT  N 

2 X 

ALPHA. 

GR3  UP 

? ECDE 

UNPDY  REASN 

PATTN  ALPHA. 

NOTE  — 

NEXT 

FIELD  IS  DECIMAL  (DECHL). 

FIELD 

YRDTG 

2 X 

DECHL. 

FIELD 

DADTG 

3 X 

DECHL  . 

GROUP 

TIDTG 

YRDTG  DAD  TO 

• 

FIELD 

HRDTG 

4 X 

DECHL. 

FIELD 

TZDTG 

1 X 

ALPHA. 

GROUP 

RAETG  ' 

TIDTG  HRDTG 

TtDTG. 
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FIELD  OMIT  12  X ALPHA. 

FIELD  ONAHE  27  X ALPHA. 

FIELD  DPCOM  6 X ALPHA. 

MOTE DEFINE  1ST  REPEATING  RECORD  FORMAT. 

DEFINE  1 'B*. 

NOTE NEXT  FIELD  IS  FOR  SPACING  - NDT  ACCESSIBLE. 

FIELD  FILLER  2 1 ALPHA. 

IDTE REDEFINE  RECID  ID  FIELDS,  BUT  NOT  THE  GROUP. 

FIELD  SERV  1 Cl  ALPHA. 

FIELD  OOIN  5 C2  ALPHA. 

NOTE SPACING. 

FIELD  FILLER  2 1 ALPHA. 

NOTE  REDEFINE  RECORD  TTPB  FIELD. 

FIELD  RTTPE  1 T ALPHA. 

FIELD  C OHDR  20  1 ALPHA. 

FIELD  LOC  18  1 ALPHA. 

N DTE NEXT  PIE  LD  CONTAINS  COORDINATE  DATA  IN  ALPHA  FORMAT. 

FIELD  POINT  11  1 ALPHA. 

FIELD  CNTFY  2 1 ALPHA. 

FIELD  CRAM  15  1 ALPHA. 

FIELD  GEPOL  2 1 ALPHA. 

NOTE SPACING  TO  END  OF  RECORD  FORMAT. 

FIELD  FILLER  5 1 ALPHA. 

NOTE  DEFINE  2ND  REPEATING  RECORD  FORMAT. 

DEFINE  2 »C». 

NOTE SPACING. 

FIELD  FILLER  2 2 ALPHA. 

NOTE  REDEFINE  RBCORD  ID. 

FIELD  SER?  1 Cl  ALPHA. 

FIELD  0U IN  5 C2  ALPHA. 

N DTE SPACING. 

FIELD  FILLER  2 2 ALPHA. 

NDTE  REDEFINE  RBCORD  TYPE 

FIELD  9 TTPB  1 T ALPHA. 

NOTE SPACING  TO  FORCE  ALIGN  RENT  OF  NEXT  FIELD. 

FIELD  FILLER  1 2 ALPHA. 

NOTE PERS  IS  BINARY  NON  ERIC  FIELD. 


■ DTE POOR  BYTES  ON  FOLLNORD  BOUNDARY. 


FIELD 

PERS 

6 

2 

NUMBR 

FIELD 

ACTI? 

2 

2 

ALPHA 

FIELD 

LAUD 

10 

2 

ALPHA 

FIELD 

LYN 

1 

2 

ALPHA 

FIELD 

ONTYP 

5 

2 

ALPHA 

t 

| 
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FIELD 

TPNAR 

42 

2 

ALPHA. 

NOTE  — 

... 

— DEFINE 

3RD 

REPEATING  RECORD 

PORHAT. 

DEPINE 

3 

• F ' . 

NOTE  — 

— REDEPINE  RECORD 

ID  AND  TYPE 

FIELDS. 

PIELD 

PILLER 

2 

3 

ALPHA. 

FIELD 

3 ERV 

1 

Cl 

ALPHA. 

FIELD 

(JOIN 

5 

C2 

ALPHA. 

PIELD 

PILLER 

2 

3 

ALPHA. 

PIELD 

R TYPE 

1 

T 

ALPHA. 

NOTE  — 

... 

— DEFINE 

REST 

OP  PORN  AT. 

PIELD 

PLAN 

4 

3 

DECHL. 

PIELD 

PLFAC 

1 

3 

ALPHA. 

FIELD 

PLDTG 

1 0 

3 

ALPHA. 

PIELD 

PLFST 

1 

3 

ALPHA. 

FIELD 

PLPDG 

1 0 

3 

ALPHA. 

PIELD 

PLRT 

6 

3 

ALPHA. 

PIELD 

PLTRT 

6 

3 

ALPHA. 

NOTE  — 

— DEFINE 

4TH 

REPEATING  RECORD 

FORHAT. 

DEFINE 

4 

•G*. 

NOTE  — 

--  REDEFINE  RECORD 

ID  AND  TYPE 

FIELDS. 

FIELD 

FILLER 

2 

4 

ALPHA. 

FIELD 

3 ERV 

1 

Cl 

ALPHA. 

PIELD 

UOIN 

5 

C2 

ALPHA. 

PIELD 

FILLER 

2 

4 

ALPHA. 

FIELD 

R TYPE 

1 

T 

ALPHA. 

FIELD 

TRTY 

6 

4 

ALPHA. 

NOTE  — 

- 

DEFINE 

5TH 

REPEATING  RECORD 

PORHAT. 

DEFINE 

•H'. 

NOTE  — 

- 

•-  REDEFINE  RECORD 

ID  AND  TYPE 

FIELDS. 

FIPLD 

FILLER 

2 

5 

ALPHA. 

FIELD 

SER  V 

1 

Cl 

ALPHA. 

t FIELD 

DIJIN 

5 

C2 

ALPHA. 

j FIELD 

PILLER 

2 

5 

ALPHA. 

FIELD 

RTYPE 

1 

T 

ALPHA. 

' PIELD 

SUBUIC 

6 

5 

ALPHA. 

FIELD 

S DBF  LG 

1 

5 

ALPHA. 

NOTE  — 

... 

— DEFINE 

6TH 

REPEATING  RECORD 

FORHAT. 

DEPINE 

6 

•I*. 

NOTE  — 

... 

— REDEFINE  RECORD 

ID  AND  TYPE 

PI ELDS. 

FIELD 

FILLER 

2 

6 

ALPHA. 

J FIELD 

5 ERV 

1 

Cl 

ALPHA. 

FIELD 

DDIN 

5 

C2 

ALPHA. 

| FIELD 

FILLER 

2 

6 

ALPHA. 

: i 
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FIELD  R TYPE  1 T ALPHA. 

MOTE SPACE  FOR  ALIGNS  EHT. 

FIELD  FILLER  1 6 ALPHA. 

NOTE VSZ6  IS  THE  SIZE  FIELD  FOR  THE  VARIABLE  FIELD 

IN  THIS  SET. 

NOTE  IT  MUST  BE  AN  ALIGNED  FULLHDRD  BINART  FIELD. 

FIELD  VSZ6  4 6 NUHER. 

NOTE REFER  IS  A VARIABLE  FIELD. 

FIELD  REFER  50  V6  ALPHA. 

END. 

/* 
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Section  4 


FILE  REVISION 


File  Revision  (FR)  revises  the  for* at  ia  which  data  is 
st  >red  in  an  FFS  data  file.  FP  provides  the  restructuring 
of  an  existing  data  file,  allowing  the  insertion  or  removal 
of  fields  or  sets  of  data  and  also  allowing  for  a new 
optional  file  block  size. 

File  Revision  will  coapare  the  FFT  describing  the  file 
in  its  current  forsat  with  the  FFT  describing  the  file  in 
its  revised  forsat.  FR  will  then  generate  ?H  logic 
statesents  which  will  be  used  by  FH  for  copying  selected 
data  eleients  into  the  new  forsat. 

FR  will  process  data  on  a field  basis  only.  It  will 
persit  the  addition,  deletion,  and  liaited  relocation  of 
fields  as  well  as  changes  to  their  storage  node,  size,  and 
nane.  Storage  node  (alphabetic,  zoned  decisal,  binary, 
coordinate)  changes  are  pernitted  with  two  exceptions.  FP 
will  not  allow  a binary  or  zoned  decisal  field  to  be  changed 
to  a coordinate  field,  nor  will  it  allow  a coordinate  field 
to  he  changed  to  a binary  or  zoned  decisal  field.  Field 
sizes  sust  confors  to  File  structuring  rules.  Alphaseric 
fiald  size  changes  result  in  truncation  or  blank  padding  on 
the  right.  Zoned  decisal  field  changes  in  truncation  or 
zero  fill  on  the  left.  Specification  of  nuseric  (binary) 
field  size  changes  affect  only  the  external  representation 
of  the  field. 

Periodic  sets  say  be  deleted  or  relocated.  They  say 
also  be  added,  but  no  data  will  be  included,  as  a direct 
result  of  FR,  ii  either  new  sets  or  fields.  FR  will  persit 
fields  fros  any  set  in  the  old  file  to  be  split  into  several 
sets  in  the  new  file.  It  will  not  persit  fields  fros 
sultiple  sets  in  the  old  file  to  be  serged  into  one  set  in 
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th?  new  file.  There  is  no  say  for  PR  to  logically  connect 
the  subsets  of  two  existing  sets. 

PR  will  persit  the  addition  of  sajor  or  subset  control 
fields.  Major  or  subset  control  fields  say  be  deleted  is 
long  as  the  reta  ined  control  fields  (i.e.  , the  control 

fields  cosson  to  both  the  old  and  new  files)  provide  a 

unigue  hey  for  each  record.  Control  fields  say  be  added  and 
deleted  within  the  sane  PR  run  if  the  retained  control 

fields  provide  unigue  keys.  Tf  the  retained  control  fields  ^ 

will  not  provide  unigue  keys,  two  PR  runs  aust  be  aade:  the 
first  to  add  the  additional  fields,  and  the  second  to  delete 
unwanted  control  fields.  If  two  PR  runs  are  aade,  none  of 

the  control  fields  fron  the  first  file  will  be  retained  in 

the  final  file. 

Tha  revised  file  will  contain  only  the  FPf , the  logic 
stateeants  for  the  report  *PR',  and  the  data  records. 

Before  the  user  processes  his  new  file,  he  Bust  review  and 
notify,  as  reguired,  hia  old  logic  stateaents,  queries, 

RITs,  tables,  and  subroutines  to  ensura  compatibility  with 
his  new  file  design.  The  logic  stateaents  aust  be 
recoeplled  and  added  to  the  logic  stateaent  library  (report 
'PR'  should  be  deleted!  . Other  aaterlals  aust  be 
recoapiled , as  required,  and  placed  on  the  appropriate 
library. 


4.1  PR  Description 

The  user  structures  an  PPT  describing  the  file  in  its 
revised  foraat.  He  then  executes  the  procedure  XFR, 
identifying  both  old  and  new  files,  field  naae  changes,  and 
the  PR  output  and  processing  options.  This  procedure  causes 
execution  of  the  control  prograa  PR.  This  prograa  calls  the 
routines  to  process  the  user's  control  deck,  the  old  PPT, 
and  the  new  PPT;  it  also  produces  the  logic  stateaents  that 
aay  be  coapiled  and  executed  through  linkage  to  the  Pile 
Maintenance  (PM)  coaponent. 

Aftsr  identifying  and  processing  the  control  options,  PR 
will  develop  a naae  change  table  froa  the  reaaining  input 
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parameters.  Another  table  will  be  developed  froe  the  field 
description  records  in  the  revised  FFT. 

Having  acconplished  this  initialisation.  File  Revision 
will  read  the  current  FFT  and  generate,  for  each  set  type, 
an  FRS  logic  statement.  inf  Secondary  Indexing 
specification  east  be  provided  by  the  user  when  the  new  FFr 
is  structured.  The  data  required  to  generate  indexing 
in  oraation  will  be  provided  by  FB. 


FR  will  build  a data  sat  containing  FHS  control  records 
and  the  generated  logic  stateaents.  The  data  set  or 

selected  portions  of  it  nay  be  punched  and/or  printed.  The 

user  aay  use  the  FR-generated  logic  stateaents,  with  or 

without  aodification,  in  subsequent  independent  FH 
executions. 

Additionally,  FR  will  print  an  FFT  conparison.  This 
comparison  will  indicate  the  field  nase,  size,  storage  node, 
an  1 set  nuaber  for  each  field  in  both  the  current  and 
revised  files.  It  will  also  annotate  all  changes  with  the 
appropriate  renarks. 

At  the  successful  conpletion  of  FR,  FH  will  be  executed 
to  conpile  the  generated  logic  stateaents  for  report  'FR* 
anl  will  execute  then  to  generate  tbs  revised  file.  The  old 
file  data  records  provide  the  transactions  to  the  FR 

gens ration  phase. 


4.2  Processing  Flow 

Figure  3 illustrates  the  processing  fLow  of  the  File 
Revision  process. 
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4. 2."'  Details  of  Processing 

This  section  describes  the  major  functions  performed  by 
each  pass  of  the  Pile  Revision  process. 

FR  - FR  Supervisor. 

Links  FP  subroutine  PBSUP. 

Tests  and  links  to  FF  component  dependent  on 
results  from  FR  execution. 

FRSUP  - FR  Subroutine  Caller. 

Peads  File  Revision  specifications. 

Stores  FR  run  options. 

Calls  all  FR  subroutines. 

Regains  control  after  each  subroutine 
and  prints  error  messages  as  appropriate. 

FRKtflP  - FR  card  scanner. 

Isolates  and  interprets  FR  parameters. 

Builds  table  1 of  identifiable  keyword 
parameters . 

Builds  ♦•able  2 of  name  change  specifica- 
tions and  unidentified  keyword  parameters. 

FRINIT  - FR  Initializer. 

Reads  the  FFT  for  the  new  file. 

Builds  table  3 of  new  FFT  field  information. 

Builds  table  4 of  new  FFT  control  field 
locations. 


FRGEN1  - FR  work  record  builder. 
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Combines  old  and  new  specifications  for 
related  data  fields. 

Builds  28-cha  rac  te  r records  containing 
field  na  ae , size,  set,  and  storage  node. 

Writes  these  records  on  to  the  file 
•FRWK1*,  which  is  then  sorted  by  old 
set  nuaber,  new  set  nuaber,  and  old  field 
location  within  set. 

PRGFN2  - PR  Generator. 

Reads  the  sorted  work  file  •PRWK2*. 

Generates  TDD  control  card  iaages  to 
describe  the  old  data  file  which  is  to 
be  used  by  PH  as  a data  source. 

Generates  POOL  control  card  iaages  to 
perfora  the  required  aoveaent  of  data 
froa  the  old  to  the  new  file. 

Outputs  TDD  cards  and  POOL  stateaents  on 
separate  data  sets,  for  use  by  'FROOT'. 

Prints  an  analysis  of  the  PR  action  to  be 
perforaed  with  each  field. 

P ROOT  - PR  output  subroutine. 

Coabines  PNS  and  library  action  control 
card  iaages  with  the  TDD  and  POOL 
generated  by  • PR  GBR  2 ' . 

Writes  out  data  sets  containing  control 
card  inforaation  to  perfora  logic 
stateaent  coapilation,  library  action,  and 
file  generation. 
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Prints  and/or  punches  the  generated  logic 
statements  as  required. 

Returns  control  to  FRSUP  which  will  in  turn 
pass  control  to  the  supervisor,  PR,  to  link 
and  execute  the  Pila  Maintenance  (PH)  component . 


4.  } pr  Input 

Tha  followiig  paragraphs  describe  input  data  sets  and 
coi  trol  cards. 


4.  <.  1 Old  Data  Pile 

Tha  aid  360  FPS  data  file  (the  file  to  be  revised)  may 

be  either  a Sin,  an  ISAM  or  a VS Afl  lata  file.  The  file 

organization  is  identified  by  using  the  'SAH',  'IS AH*  or 
• VS  3 LDf ' parameters  on  the  XPR  execute  card. 

As  the  old  data  file  is  usad  as  the  transaction  source 

to  the  generate  phase  of  PH,  an  additional  parameter 

•TRANTTP'  must  be  used  to  identify  the  file  organization. 

I This  parameter  must  equal  SAH  if  the  old  data  file  is  SAN, 

or  VSAN  if  the  old  data  file  is  VSAH.  If  old  data  file  is 
ISAM,  the  TRANTTP  parameter  will  default  to  ISA N. 


4.3.2  New  Pile  Pormat  Table 

Before  running  Pile  Revision,  the  new  PFT  must  be 
. structured  and  aust  reside  on  direct  access  storage  is 

either  an  ISAM  or  VSAH  dati  set.  The  new  PFT  is  sequential 
' organization.  The  new  PFT  is  identified  by  using  the 

'NEW PFT'  parameter  on  the  XPR  execute  card  for  an  ISAM  PFT 
or  ths  'VSDSN'  parameter  for  a VSAH  PFT.  The  PFT  name  need 
not  be  the  same  as  the  old  file  name. 
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4.3.3  Car  d Input 

Fils  Revision  control  cards  are  free  foraat  and,  with 
ths  exception  of  the  field  naie  change  cards,  use  keywords 
to  identify  paraaeters.  Since  the  field  naie  change 
intonation  is  not  identified  by  keywords,  all  of  the  field 
naie  change  information  iust  follow  the  keyword-identified 
intonation  in  the  user’s  input  deck.  Furthermore,  no 
extraneous  intonation,  such  as  comments,  may  be  punched  on 
any  of  the  user’s  control  cards,  since  FB  will  interpret 
this  information  as  field  name  change  information. 

The  sequence  of  keyword-identified  information  will  be: 
KEYWORD,  VALUE,  KEYWORD,  VALUE,  etc.,  with  no  fixed  format 
or  parameter  sequence  requirement.  The  user  may  enter 
multiple  paraaeters  after  a single  keyword  if  the  parameter 
list  is  enclosed  in  parentheses.  Any  number  of  blanks  may 
separate  keywords  and  values  from  their  connecting  equal 
sign;  e.g.,  KEYWORD VALUE.  Any  number  of  blanks  and/or 
commas  ray  separate  keyword/value  pairs;  e.g.,  FILE  = 
TESTA  ,NEWFILE  = TESTB  PRINT  = ALL. 

Special  characters  othar  than  the  comma,  equal  sign  and 
parenthesis  are  not  valid  in  File  Revision  control 
statemeits. 

Processing  options  such  as  PUNCH,  PRINT,  etc.,  and  file 
name  identifiers  are  keywords.  All  other  words  found  in  the 
keyword  positions  are  assumed  to  be  old  field  names,  and  the 
words  following  them  are  assumed  to  be  the  new  names. 

valid  input  paraaeters  are  listed  in  the  following 
paragraphs. 

0 ID  FI  LB  or  E1LE  specifies  the  name  of  the  data  file  to 
be  converted.  This  parameter  is  required. 

iLHEILS.  identifies  the  revised  fLle  name.  If  the  file 
name  does  not  change,  this  parameter  is  unnecessary.  If 
this  parameter  is  not  specified,  the  old  file  name  will  be 
used  as  the  file  name  for  the  revised  file. 
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The  SBIjll  parameter  is  optional.  E&II.Z  causes  the 
printing  of  the  generated  logic  stateaents.  It  any  be 
followed  by  the  nor  d iU  to  cause  the  printing  of  all  the 
stateaents  or  by  the  desired  set  nnnbers.  If  the  set 
nuabers  are  used  and  sore  than  one  set  is  desired,  they  aust 
be  enclosed  in  parentheses  and  separated  by  coaaas;  e.  g. , 

PRINT  = (1,  4,  7,  23) 

The  {MJjJCH  pacaaeter  is  optional.  PUNCH  causes  the 
punching  of  the  generated  logic  stateaents.  The  operands 
which  aay  be  used  are  the  sane  as  those  for  the  ffHX 
paraaeter. 

NOGO  is  an  optional  paraaeter  followed  by  PH,  indicating 
that  the  File  Revision  job  should  teraiaate  just  before 
execution  of  File  Maintenance. 

Field  naae  changes  are  input  in  the  fora  - 
old-f ield-naae  3 new- field- naae 
and  aust  follow  all  keyword-identified  paraaeters. 


4.4  FR  Output 

The  following  paragraphs  describe  the  output  of  File 
Revi sion. 


4.4.1  R evised  File 

If  no  errors  are  detected  by  the  PR  prograa  (and  the 
user  has  not  selected  the  NOGO=PH  option),  a revised  file 
will  be  produced.  This  file  will  always  be  a sequential 
fils,  and  unless  the  user  specifies  the  device  type  by  using 
the  'NEWOSAH'  paraaeter  on  his  execute  card,  it  will  reside 
on  the  device  type  specified  by  the  default  paraaeters  in 
the  Pus  A no  UT  DD  stateaent.  The  new  file  will  consist  of  the 
fft  , the  Logic  3tatesents  that  were  created  by  FR  to  create 
the  file,  and  the  data  records.  The  old  logic  stateaents 
wllj  not  be  carried  over  to  the  new  file.  The  file  naae 
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will  either  be  the  saee  as  the  old  file,  or  the  sane  as  the 
user  specified  in  his  PR  control  deck,  using  the  ' RE  IfPI  LE  • 
parameter.  The  nev  file  Hill  be  cataloged.  If  the  old  file 
Has  sequentially  organized  and  its  naae  Has  used  for  the  nen 
file,  it  will  be  uncataloged,  otherwise,  the  old  file  Hill 
reaain  cataloged.  The  block  size  of  the  nen  file  Hill  be 
the  sate  as  the  old  file  unless  the  user  specifies  a nen 
block  size  using  the  BSZNBP  syabolic  paraaeter  of  the  XPF 
procedure. 


4.4.2  Index  Data  Set 

If  indexes  were  specified  for  the  revised  data  file,  an 
Index  Data  Set  will  be  created.  The  paraaeters  necessary 
for  creating  this  data  set  aust  be  provided  by  syabolic 
paraaeters  of  the  1FR  procedure. 


4.4.3  Printer  Output 

FR  produces  three  types  of  printer  output. 

The  first  list  consists  of  a print-back  of  the  user's 
control  deck,  with  appropriate  error  consents. 

The  second  printer  output  consists  of  a comparison  of 
the  old  and  new  PFTs,  with  field  changes  indicated  and  any 
illegal  field  changes  noted. 

Tha  third  printer  oitput  consists  of  a list  of  the 
genarated  logic  statenents  that  the  user  requested  to  be 
printed  by  using  the  PRINT  paraaeter  in  his  control  deck. 
Ona  logic  statement  will  be  created  for  each  old  set, 
provided  all  the  fields  in  a given  set  were  not  deleted. 
Thay  will  be  printed  in  set  sequence. 

Following  the  PR  printouts,  the  noraal  PH  printouts  will 
appear,  showing  the  coapiled  logic  statenents,  transaction 
processing  errors  which  would  indicate  deletion  of  a set, 
and  confirnation  aessages. 
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4.4.4  Punched  Output 

FR  uill  punch  the  generated  logic  statements  for  the 
sets  requested  in  the  PORCR  paraaeter. 


4.5  FR  Exaaples 

The  following  exaaples  illustrate  typical  uses  of  File 
Revision. 


4.5.1  Saiple  Revision  with  Two  Naae  Changes 

FILE  = TESTA,  SEW  FILE  = TESTB 
PORCH* <4,  7 , 9) 

PRIRT-ALL 

ARRTIH  = ATA, 

RUHBR  = FLTRBR 

The  current  file  naae  is  TESTA,  and  the  revised  file  is 

to  be  TESTB.  The  user  specifies  that  the  logic  stateaents 

ani  FH  control  records,  which  are  generated  for  current  file 
set  numbers  4,  7 and  9,  are  to  be  punched.  All  the 

gsnaratad  logic  stateaents  are  to  be  printed.  The  naaes  of 
the  two  current  file  fields  ARRTIH  and  HOHBR  are  to  be 

changes  to  ATA  and  FLTRBR  In  the  revised  file. 


'4.5.2  File  Structure,  Revision,  and  Haintenance 

An  illustrative  exaaple  of  a file  revision  run  can  be 
found  in  Vol.  VIII,  Job  Preparation  Annual. 


4.5  File  Revision,  Special  Considerations 

File  Revision  typically  involves  adding  or  deleting  of 
data  fields  and/or  periodic  sets.  It  aay  also  involve 
changes  in  node,  size,  or  location  of  data  fields.  These 
actions  vi.ll,  in  aany  cases,  change  the  relative  location  of 
data  elements  within  a set.  Although  sone  existing 
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retrievals  and  report  instruction  tables  say  still  be  valid, 
it  is  recoaaended  that  the  user  recompile  then  and  store 
than  os  the  appropriate  library  to  preclude  production  of 
erroneous  output.  File  Maintenance  logic  stateaents  §ust  be 
recompiled  and  stored  on  the  revised  file.  This  will 
preclude  inadvertent  destruction  or  degradation  of  the 
revised  file. 

In  order  to  revise  a segmented  SAN  data  file,  a definite 
process  nus*  be  followed.  Each  segaent  of  a segaented  data 
file  aust  be  revised  in  chronological  order  based  on  Record 
ID's.  If  the  Record  control  field  changes,  the  Drder  should 
be  based  on  the  new  Record  control  fields  expected.  In 
general,  revising  the  Record  control  fields  is  not  advised. 

The  first  step  should  be  creation  of  the  FPT.  The 
execution  of  PR  should  be  done  with  the  N0G3  option  allowing 
storage  of  the  PR  logic  stateaents.  The  third  step  would 
involve  a SAN  segaent  generation  run  with  a segaent  control 
record  to  define  the  segaent  boundary  for  the  first  segaent. 
The  FPT  and  Logic  stateaents  on  the  ISAH  or  ?SAN  FFT  aust  be 
used  for  each  generation  of  a segaent.  Each  segaent 
generation  aust  include  a segaent  control  card. 
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